Duwamish7架构分层分析

Duwamish7架构分层分析

1.总的感觉：
使用的不是一种纯粹的OO的实现方法，基本上可以看作一种组合良好的事务脚本的写法。
但是这种写法我个人不是很推荐，关键有下面几点遗憾：
1)没有用OO的写法，而将实体的数据部分放在了Common,而将它的方法又散落到了BusinessRules/BusinessFacade。(按Duwamish7的分层方法也说得过去，但是总是感觉不大舒服)
2)用自定义的dataset来传递数据，dataset定义得较复杂，不易理解，估计也不好维护。

2.BusinessFacade:业务外观层
以功能分，提供若干系统的功能的外观类,如ProductSystem等。
1).bf层可以看作是控制类的层，它调用DataAccess层的数据访问类来访问数据库，由此完成特定的业务操作，如CRUD操作。
2).局限性：在系统逻辑较少时，可以直接用ProductSystem类来表示一类服务，但是系统功能多时，就必须分出多个类来了。
这个外观层做得很有意义，可以提供一个更明确紧凑的“服务层”给客户调用，而且也可以尽可能减少将业务逻辑放在UI层来实现。

3.DataAccess层：
数据库访问层，也就是写sql调ado.net的相关类访问DB的层
1).失败的地方：每个类的方法都直接写ado.net的方法来访问数据库，没有提供一个DBHelper类来统一访问。
2).命名也失败：DB层的类最好以DB后缀，如BookDB.cs,否则与BusinessRules等几个工程的类容易混淆，增加不必要的麻烦。

4.Common层：
可以看作是一个实体类层。自己定义了Dataset，BF、DB、Rule层就用那些dataset来传递数据。
不是很舒服，主要是：
1)这种实体类只有数据没有行为，算是"哑类",除了传递数据外没有其他用处。通常实体类映射现实的一个事务，OO的通常做法是数据和方法是放在一个实体类里的，这样又必须一些实体对应的行为放到BF/Rule层去了，不是推荐的做法。参考所谓的“信息专家模式”。
2).用dataset来表示一个实体，里面又有若干datatable,这种用法个人是比较少见，一般都是直接用单个datatable来做了。我只在WinForm的datagrid里用过dataset，那主要是因为datagird的datasorce就设为dataset了，方便使用。

5.BusinessRules 业务规则层
bf层直接调用db层完成了一部分CRUD的操作，但涉及到较复杂的业务规则计算的逻辑，放在了Rule层，而不是直接放在bf层。Rule层也调db来访问数据库。这可以算是一个亮点，因为它把一些复杂业务逻辑抽出单独放在一层里了，否则就得像通常我们写三层代码时全放在“业务逻辑层”了。这样如果要修改这些业务逻辑就很方便高效了。(看了Duwamish7终于知道vs.net的企业模板自动生成的BusinessRules是搞什么的，最近想优化一下公司代码的分层，原本有些“服务层”的逻辑没地方放本想放在Rule里的，现在看来不太适合了)

上面提了我个人感觉到若干Duwamish7的不佳的地方，因为最近考虑一下架构分层，匆匆看看所感，有谬论欢迎指正。现在才谈Duwamish7题材老了点，作为个人一点资料备份暂且还是post上来吧。