关于现在使用的分层架构的一点反思

现在项目中使用的架构大概如下图，一个典型的分层架构，从PetShop学习得来，当时认为业务逻辑是不可能更换的，所以便去掉了IBLL层，但是现在看来这一层还是很有必要的，不同的时候看同一件事就会有不同的看法。

UI层主要是收集数据和显示数据。 

Model层主要是一些贫血的实体类。

BLL层主要负责业务逻辑的处理。 

IDAL是数据访问接口层。

DALFactory主要负责数据访问对象的构造，这里主要是用到了反射来创建对象。

DAL层实现数据访问接口。 

这个分层架构的好处是各个层的职责更加明确，同时由于通过接口来处理数据存储，所以理论上可以实现多数据库支持。

对于一般的项目，这个架构也算是足够了。 

但是仔细分析会发现有很多问题： 

1. 各层之间的相互依赖太多。Model层几乎被所有的层引用，除了DALFactory
2. 虽然架构上可以支持多数据库， 但是如果真的通过新建项目的方式来支持多数据库的话，则工作量太大。
3. 一般项目都会包含多个模块， 这样各个模块的代码都会混在一起，等到要拆分或者移植到其它系统的时候会发觉各个模块的代码耦合在了一起，不好分离。
4. 这个工厂类也比较纠结， 如果用自定义的配置结来配置，则要写一堆代码；如果直接加到AppSetting，则一堆Key.

如果现在让我重新来设计的话，我会采用下面的架构：

 

1.  将model层， IDAL数据访问接口层和IBLL接口层的代码放到一个项目中， 暂时称为模块核心层，即Core层。
2. 有一个独立的核心组件， 包括创建对象的工厂，持久层框架，日志，缓存和工具类等。
3. 各个模块之间的依赖通过接口来解决。

这样，各个模块的可移植性就增强了。 

最好还有这样一个功能，像CSLA中的一样，比如创建了一个windows客户端， 可以直接连接数据库进行操作， 也可以从连接Web Service时行操作，还可以连接Remoting进行操作， 在这之间的切换只需要修改一下配置就可以了，但只需要写一个业务逻辑，不用在项目中强制引用Web Service，这样就更完美了。

 大家有什么看法？