我最近学习的WCF,自己的理解如下:
对于WCF主要有两部分,一个是客户端的,一个是服务端的,客户端直接调用服务端的接口就行了,至于如何实现就是服务端的事情。WCF在服务端实现的主要是三层架构,数据契约DC层,业务逻辑BLL层,和数据处理的DAL层。每一层的分工很明确。DC是讲需要的数据进行封装,在处理相关业务的时候,先从DAL层开始,对数据进行初步的增删改查,读取操作。在这一层只是初步的处理。然后将初步的数据返回到BLL层也就是业务逻辑层进行详细复杂的处理加工。所有主要的复杂操作都是在BLL层完成的。完成之后服务端的接口实现只需要调用BLL层处理好的数据就行了。WCF这三层架构的分工很明确。可以试用大型项目的开发操作。基本就是对数据和数据操作的封装。这种封装的思想不仅仅在WCF服务上才能使用,在任何的项目开发中都应该有这种意识:尽量的将工作分开,尽量的将集中处理的数据操作进行封装,只留出一个接口。这样别人在使用这个功能的时候并不需要去了解里面的实现就可以很方便的调用。这样对于代码的可复用性非常高。
很不错的,我记得Microsoft .NET企业级应用架构设计 这本书里面讲到过这种模式。不要纠结是三层什么的。个人觉得这个架构很不错。
如果你把所以的逻辑都最后通过WCF来发布的话,原则上来说,你这个架构可以适应任何的客户端。
对了这本书里面说的服务层是一个范称,一切再次封装了domain(bll)为UI服务的貌似都称为service,单人WCF是其中之一。
简单点理解 大致也是这样的了
我觉得WCF中的BLL层的业务逻辑没什么必要。服务端提供数据接口是没错 但是不能提供面面俱到的数据,否则以后客户端的数据需求变化了岂不是还要增加服务端的接口。
思想差不多了,就是 后面的 每层建多少个类库问题,这个根据实际情况来,
一层的含义不是说是一个类库,而是逻辑功能上的一层,一般包含多个类库。
一般理解应该就是这样,但具体怎么应用还是看项目吧。我开发时,喜欢先把关键的功能快速实现,然后花些时间重构它,差不多了,再进行开发,一个阶段后再去重构,软件也是个持续改进的东西吧。