今天没事瞎逛到 田兄的 Blog 看到了 一篇关于多层架构的文章《度》，刚好前段时间在 LanZhou Office 培训的主要内容也是涉及到多层架构 ，当时大家也提出了一些相似的观点和困惑 废话不多说 ，谈一下我的观点：

田兄举了一个添加学生信息数据的例子（虽然有网友提出异议，但我觉得还是比较典型） 需求就是将学生数据录入到数据库中

使用多层架构实现如图：

和田兄的结构稍微有些不同， 偶比较喜欢加入一个Entities包来放置实体类。另外ValidInfo这个方法偶放置在StudentManager里面因为验证信息是否可用应该不是属于Student具有的方法 （参考这里）

 

 

 

而单层结构的实现 ，使用SqlDataSource似乎更简单易用（直接参考田兄的代码了）

首先我们看到的是多层架构的做法比起单层结构来说要复杂的多，田兄也讲到这个简单的例子看似只多出20行代码但是如果在一个项目中有50个大同小异的功能点，代码量的增加就可以达到一个需要关注的程度，而且根据做多错多的原理 ，多层架构的劣势似乎更加打明显。在兰州Office 的时候WTM也和我讲到感觉用多层架构根本没有意义，反而把事情越高越复杂 。

我非常喜欢田兄这篇雄文的标题“度”，同样XP也一再强调不要背上太多包袱～

这里首先应该澄清的是我们的项目是什么样的项目，如果是一个个人网站或者一个非常小需要1～2个人在2/3个月内的项目（后期的维护，更新也属于有限责任制），那么我绝对支持单层结构。（你甚至可以用nettier帮你搞定所有的东东，关于Case和ORM这篇文章不讨论）

但如果是大项目，公司产品这样的东东 吼吼 ，对不起^_^ 不管你觉得的多么的麻烦，还是相信我使用多层架构。

 

• 田兄在文章中指出开发效率和代码质量， 其实也有网友提出异议， 我个人也觉得这里有点小问题 ， 前题是这个项目到底有多少人多少时间参与，如果是一个人短时间开发，测试也不是很有保证单层结构的程序肯定比多层有优势 ，当然如果时间充足 ，对每一层都进行了比较好的单元测试 ，那么我个人认为结合起来的质量甚至比单层混合了业务逻辑的代码更有保证更好独立维护（当然分层后每个功能模块也更好独立测试）。

 

  另外很重要的一点就是如果多人开发 ， 分层以后每个人只做相对应的模块，指责明确， 做界面的制作界面 ，业务层的只用关心业务逻辑 ，数据层的关心数据层的东东， 这样比一个人又要写SQL， 又要调整Div ,Css这些东东强很多。

  试想3个人做三个差不多需求的项目 ，3个人每人分别做3个功能页面，首先3个人又要会Html, 还要会C#　同时还有Sql 。

    (这里再假设一下我们的数据库的存储过程又比较有难度，业务逻辑有比较多，页面的制作也有有复杂)

  那么不讨论3个什么都会的人的价格，就从开发的角度来说也有这3个人受的了。

  但是有如果这３个人一个人只做一块，做页面的人只关心布局　，数据库的人搞定存储过程，做业务的人专心完成业务。那么３个人可能都比较轻松，而且因为专 注，测试也是比较好进行的，就好比装修房子，刷墙的去刷墙顶，木工做吊顶，电工来装灯一样，如果一个人什么都做那他肯定比较累。

 

    Lanzhou Office 的时候大家经常抱怨几个人的代码结合的时候非常的困难，出错都不知道在哪里出错，那么请  审视每个人你们是否做出了合格的代码，做过了完美的测试，还是那句话如果每个人都能保证自己所做的那部  分正确，那么结合的时候也会very smooth !

 

•       谈到可维护性和扩展性田兄的例子是StudentEntity增加了一个属性 ，因为简单所以似乎也是实在不好说服大家，但单就这个例子而言，我还是要加入一个开发场景 ，如果单人维护确实麻烦，因为他又要改界面，又要改数据库。但是如果是一个团队，改界面的改界面， 改数据库的该数据库，改StudentEntity的改StudentEntity这样每个人改的东西都很少， 而且改完以后快速测试，维护文档（吼吼，再说就要转换话题说CMM 去了），我想应该不是一件痛苦的事情。
  

    这里另外插一点其他的东东 ：

    当StudentEntity的变化 导致影响了的很多模块，这是因为关注点散落在各个角落的问题这也确实也是面向对象程序中面临的一个问题 ， 所以AOP提供了解决方式（这里就先不讨论）， 但是相比起来封装、高内聚、 低耦合 这些优点我们也的确不能视而不见。

        我最后再一个举例子来说明分层对于扩展性的好处：

                2007.1.1 我们要做用户注册，　那么用户要输入用户名和密码，用户名必须用用户的Email做用户名，注册的时候要检查用户名是否已经被注册。

 

                2007.2.1 因为用户密码是明文存放在数据库中 ， 我们希望对用户密码进行加密后存放在数据库中 。

 

                2007.3.4 因为有人恶意注册，所以我们需要在用户注册的时候通过给用户Email发送一个验证码，用户在第一次登录系统的时候要用这个验证码登录才有有效，所以需要在用户注册的时候发送Email .

 

                …

 

                2007.6.20因为业务增长很快，网站受欢迎度远远超过公司预期的用户数目，公司需要将Access数据库换成SQL2005的数据库。

 

                ….

        大家考虑一下这几次业务需求的变更 ，如果我们单层结构做每次修改都可能牵扯到那个.aspx，小则给页面多加了一个字符， 大则破坏已有的逻辑 ，记住 设计模式的OCP开闭原就着重强调了一个软件实体应该对扩展开放，而对修改关闭，也就是说我们的灯泡坏了很有可能要吧木匠做的吊顶彻底的摧毁。那么如果分了层呢 ？

                2007.2.1

        我们维护Business Layer

        添加一个SecurityManager 具有加密方法（这样如果将来换算法我们也有地方直接维护）

        在UserManager对密码进行加密

 

                2007.3.4

        我们维护Business Layer

        添加一个EmailManager 具有发送邮件的功能。

        添加一个IDManager 产生验证码

        在UserManger中实现发送验证码

 

                2007.6.20

        新开发一个DBSQL2005UserManger 同时替换 DBAccessUserManager .

      ...

另外分层好处就是多人开发的时候我们往往不能等到数据层做好了做业务层，业务层做好了做页面 ，可能同时开工，并行开发， 那么多人协同作战的效率结果肯定远远超过了一悍将从头到尾的奔命。

 

最后对于一个项目要评估进度和价值我们往往需要将项目先分块，完成一个类多长时间（包括单元测试）， 这个类的难度级别 ，将来某一天需求变动我们增加功能多出了几个类，这几个类的成本是多少（人/月），等等总之如果这一切都沾在一起那么工作可能连当事人都不好总结了 。（所以往往看到一个页面多少money这种方式真的值得商榷）

That's all .

访客：