三层结构也开始盲目起来了

CSDN上常有人问, 不知道三层结构是什么东西, 要么就是如何实现三层架构, 如此之类

实际上不管是三层也好, 四层也好, 分层源于设计需求(决不是老板的要求, 甚至不能算客户需求)

为什么C/S模式正在纷纷的向B/S, 再往SmartClient过度? C/S模式的缺点除了编码麻烦之外, BizLogic分散在所有客户终端上, 要想修改, 非常麻烦. 为什么又要向SmartClient过渡? 这是因为B/S模式把所有BizLogic都放在Server上, 客户机资源几乎完全被浪费了.

所以说到底BizLogic(三层程序内部一般叫做BLL, Business Logic Layer)才是核心问题, 关于BLL下面的DAL(Data Access Layer), 和BLL上面的UILayer, 就算应用C/S模式开发, 一样可以做到: 比如设立一个独立的服务器用来封装数据库操作之类..

三层结构的程序不是说把项目分成DAL, BLL, WebUI三个模块就叫三层了, 下面几个问题

在你的项目里面:
1. UILayer里面只有少量(或者没有)的SQL语句或者存储过程调用, 并且这些语句保证不会修改数据?
2. 如果把UILayer拿掉, 你的项目还能在Interface/API的层次上提供所有功能吗?
3. 你的DAL可以移植到其他类似环境的项目吗?
4. 三个模块, 可以分别运行于不同的服务器吗?

如果不是所有答案都为YES, 那么你的项目还不能算是严格意义上的三层程序. 三层程序有一些需要约定遵守的规则:

1. 最关键的, UI层只能作为一个外壳, 不能包含任何BizLogic的处理过程
2. 设计时应该从BLL出发, 而不是UI出发. BLL层在API上应该实现所有BizLogic, 以面向对象的方式
3. 不管数据层是一个简单的SqlHelper也好, 还是带有Mapping过的Classes也好, 应该在一定的抽象程度上做到系统无关
4. 不管使用COM+(Enterprise Service), 还是Remoting, 还是WebService之类的远程对象技术, 不管部署的时候是不是真的分别部署到不同的服务器上, 最起码在设计的时候要做这样的考虑, 更远的, 还得考虑多台服务器通过负载均衡作集群

所以考虑一个项目是不是应该应用三层/多层设计时, 先得考虑下是不是真的需要? 实际上大部分程序就开个WebApplication就足够了, 完全没必要作的这么复杂. 而多层结构, 是用于解决真正复杂的项目需求的.

千万不要盲目上马多层程序设计, 先进的不一定就是好的. 被无数人鄙视的ASP, 正是因为他的简单性而流行, 并且依然打造出了像microsoft.com, dell.com这样巨型的站点