答案: SOA的理论已经够多了,也许我们可以来实践着在项目中采用SOA架构。
下面来自我自己的经验和理解,一家之言。
1、DTO
Data Transfer Object,或者叫Entity、Data Object。DTO是指在一个对象里面只包含所表示的实体的数据,而不包含任何操作行为。传统的OOP理论认为建立这样纯粹只包含数据的实体类是不正确的,而SOA架构为了能够在分布的、异构的平台上能够顺利的传递数据,则正需要这样的DTO对象。
SOA对DTO的要求是使用方式是:在系统的各个Layer之间传递的,就是DTO,从DAL到BLL,从BLL到各种Service Facade,从Service Facade到外面的服务消费者(包括PL),都传递着DTO。因为这个要求,DTO必须要可被序列化。
2、Layer结构
BLL是不直接对外公开的,对外公开的是在BLL之上的Service Facade,Service Facade里面通常只包含static方法,供服务消费者调用。Service Facade传递和返回的基本上都是DTO,比如:
OrderInfo GetOrder(Int32 orderID);
void UpdateOrder(OrderInfo order);
OrderInfo就是一个DTO。
3、Service Facade的通道多样性
在作为对外的服务接口上,可能提供多种通道的界面,比如可以接收WebService、.Net Remoting、MSMQ、DCOM等等方式的调用,还可能是同步的、异步的调用。所以可能需要提供各种的Service Facade。
ShadowFax通过双重Pipe解决这个问题,第一个管道专门接收各种各样调用请求,然后统一传递给第二个管道,第二个管道再通过调用BLL来处理请求,然后将结果传给第一个管道。
4、每个Service尽量细化
比如有一个Service,调用它必须对调用者进行验证,那么不如再做一个单独的Authentication Service来专门提供验证服务,因为这个单独的Authentication Service可能以后将可以提供给其他的Service使用。
5、Service各自独立(解耦)
可以想象,在一个大型的系统(甚至可以大到整个Internet)里面,如果每个模块、子系统都以Service的方式来提供给外部的服务消费者,那么各个模块和系统都是直接可扩展、可重用的。他们相互相对独立。
好像太简单了一点哈,但这就是我对SOA核心的理解了
http://blog.joycode.com/kaneboy/
上一个:“简”话设计模式(2)
下一个:架构设计中的方法学(2)——敏捷视图(1)