如何实现Service Contract的继承.docx
- 文档编号:25521553
- 上传时间:2023-06-09
- 格式:DOCX
- 页数:19
- 大小:21.66KB
如何实现Service Contract的继承.docx
《如何实现Service Contract的继承.docx》由会员分享,可在线阅读,更多相关《如何实现Service Contract的继承.docx(19页珍藏版)》请在冰豆网上搜索。
如何实现ServiceContract的继承
如何实现ServiceContract的继承
当今的IT领域,SOA已经成为了一个非常时髦的词,对SOA风靡的程度已经让很多人对SOA,对面向服务产生误解。
其中很大一部分人甚至认为面向服务将是面向对象的终结,现在的面向对象将会被面向服务完全代替。
在开始本Blog之前,我先来谈谈我对SOA和OO的区别,首先申明,这只是一家之言,欢迎大家批评指正,并且关于SO的谈论不是本Blog的主题,只是主题的引子,在这里只是简单讨论而已。
OO和SO之间具有共同的部分,在运用的领域上存在交集,只有在基于他们交集层面上谈论谁是谁非才有意义,下面是我对SO和OO的区别。
OO关注的是如何通过对实体属性和行为的封装来重塑模拟软件环境的真实实体。
对SO关注的则是对现实生活的某个任务、功能的实现,说得通俗点,就是如果做好一件事情。
所以对象是对Data和Behavior的封装,而Service则只是体现了一个Functionality。
Service是粗粒度的,这样才能导致Contract的稳定;Service一般是Stateless的,给定什么样的输入,就会有对应的确定的输出;Service是Autonomous,基本上的实现封装在Service本身之中,这样可以使它对其它的Service产生最小的依赖。
所以对Service建模是一件不太容易的事情:
Service不能太大,否则实现起来不容易,还会增加对外界的依赖;也不能太小,否则整合这个Service的成本会令你望而却步。
Service是可组合的(Composable),通过整合相关的单独的,完成某个单个Task或者Activity的小的Service,可以很容易产生一个大的Service,这个Service可以完成一个Functionality的整个流程。
比如我们现在把一个Task描述成一个Workflow,如果采用SO的原理来建模,我们可以把组成这个Workflow的单个Activity设计成一个service,然后根据具体Workflow的特点(比如可能是一个简单的Sequentialworkflow,也可能是一个基于Statemachine的workflow)加上相关的条件很容易的把这些Service整合起来,实际上通过整合集成,我们生成一个新的Service。
对OO,由于他面对的是一个的Object,具体在分布式中是一个个的Distributedobject,要建立一个Composableobject则很难(实际上这样也没有什么意义)。
在OO的概念中,一个Object的属性往往就是另一个Object,一个Function的实现往往要调用另一个Object的方法,而且这种层次结构可以无限延伸。
这样就会导致真个Object体系变得异常脆弱,经常造成牵一发动全身的状况。
用一个很时髦的词语来表达的,就是紧耦合(Tightlycouple),Object之间的强依赖关系促成了这种紧耦合的、脆弱的体系结构。
而OS则不一样,由于构成Service体系的单个Service是自治的,Service之间的调用(调用的这个词语容易让人联想到RPC,如果找一个比较贴切的词语来代替,我觉得consume比较合适)是基于Contract的,Service之间Communication是通过Message的(Message不仅仅是Data的封装,还是对整个调用的描述,同时基于XML的Message描述和Message的传递都是符合一个开放的标准的),所有这些成就了SO的松耦合(Looselycouple)。
说了这么多,可能大家都觉得我都是在赞扬SO,都贬低OO。
其实不然,上面所说的3个方面都是在讲应用的构建,而不是具体的编程模式。
我想表达的是,曾经盛行的基于OO的理论,在企业应用构架方面,已经不能满足我们的需要了,我们迫切希望一种全新的理论来指导我们进行企业应用的构架和集成,而这个理论非SO不可。
而在编程模型层面,OO仍然是不可替代的编程模式。
所以OO应用于Programming,而SO则更多地运用在Architecture。
既然是这样,我们必须有一种调和剂来调和这两个运用不同原理的两个层面的差异,实现他们之间的无缝的结合。
比如如何来对继承,多态,重载等基于OO行为的支持。
在这方面,WCF为我们提供了很好的解决方案。
所以我说WCF不但是为基于SOA的应用架构提供了技术支持,还通过相关的机制完成我们提出的这个“调和剂”的使命。
在上一篇文章[原创]我的WCF之旅(5):
面向服务架构(SOA)对面向对象编程(OOP)的支持——如何实现ServiceContract的重载(Overloading)中,我们谈到了WCF如何实现了对Overloading的支持,在这里我们通过一个Sample来讨论WCF对继承的支持。
这个Sample中,我们通过一个WCFService实现了提供天气信息的功能,或者说,我们实现了一个用作天气预报的WCFService。
1.我们照例来看看真个Solution的结构:
整个Solution由以下4个project构成:
Artech.InheritanceHierarchy.BusinessEntity:
这个Project通过定义的Class封装了在Client和Service端传递的数据,在本例中,我们定义了两个Class:
BasicWhetherInfo和WindInfo,他们分别表示Client通过Service获得的基本天气情况和刮风的情况。
Artech.InheritanceHierarchy.Service:
这个Project是我们的Service,包括ServiceContract和Service本身。
我们定义两个用作天气预报的Service:
SimpleWhetherForecast和FullWhetherForecast,前面一个只用返回简单的天气状况的数据(Conditions和Temperature),FullWhetherForecast在SimpleWhetherForecast基础上增加了提供风向和风速的数据。
http:
//localhost/Artech.InheritanceHierarchy:
一个WCFServiceWebsite,以IIS的方式对Service进行Host。
Artech.InheritanceHierarchy.Client:
Client端。
2.定义Artech.InheritanceHierarchy.BusinessEntity
BasicWhetherInfo.cs:
usingSystem;
usingSystem.Collections.Generic;
usingSystem.Text;
usingSystem.Runtime.Serialization;
namespaceArtech.InheritanceHierarchy.BusinessEntity
{
[DataContract]
[KnownType(typeof(WhetherConditions))]
publicclassBasicWhetherInfo
{
privateWhetherConditions_condition;
privatedouble_temperature;
publicBasicWhetherInfo(WhetherConditionscondition,doubletemperature)
{
this._condition=condition;
this._temperature=temperature;
}
[DataMember]
publicWhetherConditionsCondition
{
get{return_condition;}
set{_condition=value;}
}
[DataMember]
publicdoubleTemperature
{
get{return_temperature;}
set{_temperature=value;}
}
publicoverridestringToString()
{
returnstring.Format("Conditions:
{0};Temperature:
{1}",this._condition,this._temperature);
}
}
publicenumWhetherConditions
{
Clear,
Cloudy,
Overcost,
Rainy
}
}
BasicWhetherInfo包含连个字段/属性:
Condition和Temperature。
属于Condition不属于基元(Primitivetype)所以我们需要添加[KnownType(typeof(WhetherConditions))]Attribute(由于跨AppDomain的数据传递要求传递的数据先辈Serialization。
对于.NET中定义的Primitivetype,比如string,int以及其他一些常用的类型,比如datetime,WCF具有一套默认的序列化机制,但是对于另外一些类型,Serializor在执行Serialization的时候需要获得相关类型的Metadata的信息,WCF通过KnownTypeattribute向Serializor提供Metadata的信息。
)。
WindInfo中的Direction属性也是一样的原理。
WindInfo.cs
usingSystem;
usingSystem.Collections.Generic;
usingSystem.Text;
usingSystem.Runtime.Serialization;
namespaceArtech.InheritanceHierarchy.BusinessEntity
{
[DataContract]
[KnownType(typeof(WindDirection))]
publicclassWindInfo
{
privateWindDirection_direction;
privatestring_speed;
publicWindInfo(WindDirectiondirection,stringspeed)
{
this._direction=direction;
this._speed=speed;
}
[DataMember]
publicWindDirectionDirection
{
get{return_direction;}
set{_direction=value;}
}
[DataMember]
publicstringSpeed
{
get{return_speed;}
set{_speed=value;}
}
publicoverridestringToString()
{
returnstring.Format("Direction:
{0};Speed:
{1}",this._direction,this._speed);
}
}
publicenumWindDirection
{
East,
South,
West,
North,
Northeast,
SouthEast,
Northwest,
Southwest
}
}
3.定义Service:
Artech.InheritanceHierarchy.Service
我们首先来定义ServiceContract
ISimpleWhetherForecast.cs:
usingSystem;
usingSystem.Collections.Generic;
usingSystem.Text;
usingArtech.InheritanceHierarchy.BusinessEntity;
usingSystem.ServiceModel;
namespaceArtech.InheritanceHierarchy.Service
{
[ServiceContract]
publicinterfaceISimpleWhetherForecast
{
[OperationContract]
BasicWhetherInfoGetBasicWhetherInfo(stringpostalcode);
}
}
IFullWhetherForecast.cs
usingSystem;
usingSystem.Collections.Generic;
usingSystem.Text;
usingSystem.ServiceModel;
usingArtech.InheritanceHierarchy.BusinessEntity;
namespaceArtech.InheritanceHierarchy.Service
{
[ServiceContract]
publicinterfaceIFullWhetherForecast:
ISimpleWhetherForecast
{
[OperationContract]
WindInfoGetWindInfo(stringpostalcode);
}
}
我们定义了连个Interface作为ServiceContract。
其中IFullWhetherForecast继承ISimpleWhetherForecast。
这里需要注意的是虽然IFullWhetherForecast继承ISimpleWhetherForecast,但是运用在ISimpleWhetherForecast中的ServiceContractAttribute却不能被IFullWhetherForecast使用,这是因为在定义System.ServiceModel.ServiceContractAttribute,把运用在它之上的AttributeUsage的Inherited设为false,导致它不能运用到派生的Class上面:
usingSystem;
usingSystem.Net.Security;
namespaceSystem.ServiceModel
{
[AttributeUsage(1028,Inherited=false,AllowMultiple=false)]
publicsealedclassServiceContractAttribute:
Attribute
{
publicServiceContractAttribute();
publicTypeCallbackContract{get;set;}
publicstringConfigurationName{get;set;}
publicboolHasProtectionLevel{get;}
publicstringName{get;set;}
publicstringNamespace{get;set;}
publicProtectionLevelProtectionLevel{get;set;}
publicSessionModeSessionMode{get;set;}
}
}
我们接着为这两个ServiceContract定义对应的Service。
SimpleWhetherForecastService:
usingSystem;
usingSystem.Collections.Generic;
usingSystem.Text;
usingArtech.InheritanceHierarchy.BusinessEntity;
namespaceArtech.InheritanceHierarchy.Service
{
publicclassSimpleWhetherForecastService:
ISimpleWhetherForecast
{
ISimpleWhetherForecastMembers
}
}
为了代码的重用,我们让FullWhetherForecastService继承自SimpleWhetherForecastService,这样我们就不必重新定义GetBasicWhetherInfo方法了。
FullWhetherForecastService.cs:
usingSystem;
usingSystem.Collections.Generic;
usingSystem.Text;
usingArtech.InheritanceHierarchy.BusinessEntity;
namespaceArtech.InheritanceHierarchy.Service
{
publicclassFullWhetherForecastService:
SimpleWhetherForecastService,IFullWhetherForecast
{
IFullWhetherForecastMembers
}
}
4.HostService:
http:
//localhost/Artech.InheritanceHierarchy
现在我们完成了Service的定义,现在我们来Host我们定义的Service,这次我们通过IIS的方式来hostservice。
我们首先在该Website中引用Artech.InheritanceHierarchy.ServiceProject。
然后为FullWhetherForecastService定义相应的.SVC文件(由于ServiceContract的继承关系构成了一种ServiceContract的层次结构,从而导致所有定义的Operation都出现在最底层的Contract中,由于SimpleWhetherForecastService的Operation没有被FullWhetherForecastServiceOverride,所以现在我们只需要HostFullWhetherForecastService就可以了)。
<%@ServiceHostService="Artech.InheritanceHierarchy.Service.FullWhetherForecastService,Artech.InheritanceHierarchy.Service"%>
接着我们在Web.config中为Service注册Endpoint。
xmlversion="1.0"?
>
5.定义Client: Artech.InheritanceHierarchy.Client 到现在为止,我们完成了Service的定义和H
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 如何实现Service Contract的继承 如何 实现 Service Contract 继承