应用程序架构

今天重新来设计应用程序的架构,采用比较简单的架构层次:
x.DomainModels 用于定义领域模式
x.IService 用于定义调用服务的接口.
x.IService.Impls 用于实现服务接口.
x.IDataProviders 用于定义数据访问提供者的接口.
x.IDataProviders.SqlServer 实现SqlServer的数据访问实现.
x.Web 用于实现Web的界面的应用.

这里的x.IService.Impls其实使用SOA中常见架构经常叫为component层,但我个人认为用x.IService.Impls这个接口对于不了解SOA的人来说更容易理解些.一看就知道与x.IService之间的关系.
这里的IService是一个粗粒度的服务接口,不是一个DomainModels一个XService,而是多个紧密相关的DomainModels一个XService,而这里的IDataProvider则是一个XService一个XDataProvider这样的一种方式.

这里还有两个问题,需要思考
首先：x.Service采用粗粒度的对象会不会让Service过于复杂,因为Service中还需要处理异常的日志记录问题,事务问题,安全等问题.
其次：如何将企业服务添加到这个结构中来，看起让结构也很正常。

这里需要重点解决的问题，我想是第二个，因为每一个检查，记录日志等问题，最多不过在一个方法中多添加两行代码。并且整个程序的结构不产生问题，应当是一个战术级的问题。
而如果没有将企业服务以好的方式加入则会让程序的结构不清晰。这里需要了解到一个企业服务的引用不但包括服务接口和本地代理实现，还包括接口的数据交换模式(DataContract)。这里可以通过以下方式来处理：
    第一种方式：在X.IServices层中生成调用接口，在X.IServices.Impls调用本地代理类，在X.DomainModels中生成数据交换模式（DataContract)。
    第二种方式：在X.IServices层生成服务接口，本地代理实现和DataContract。
    第三种方式：在X.IServices.Impls中添加企业服务的本地代码。
    第四种方式： 新建工程X.EnterpriseServicesRef生成企业服务的本地实现。
    通过第一种方式的好处在于与应用程序的架构所使用到的方式相同，这样看起来结构比较清晰，如果是Web层与业务层采用不同的人开发，能够有效的减少Web层开发者的难度。但也出现了问题，如果企业服务的发生变化，需要进行生机会影响到三个工程，并且还需要手工将SvcUtil.exe生成的代码复制到三个工程之下，并且DataContract针对于IDataProvider而言，没有一点帮助。
    采用第二种方式可以让IDataProvider对于DataContract的了解，但我们不能够假设一个服务的实现中可能会调用那些企业服务啊。因为接口不应当对于实现有任何假设，并且架构的层次也发生了变化。
   采用第三种方式，虽然对于服务接口这一部分的问题解决了，但如果WEB层需要访问企业服务所提供的功能又不行了。
   看来只有采用第四种方式，需要这个工程的就添加对这个工程的引用，这个工程用来引用所有与企业服务相关的内容。这里通常只有Web层和IServices.Impls会添加对这个工程的引用，并且看起来也结构也很清晰。