为业务逻辑层正名：欢迎大家谈谈如何划分三层架构
关于什么是三层架构，眼下应该算得上是“老少皆知”，在此就不谈了。此贴只想让大家一起讨论一下如何划分三层。我首先抛砖引玉，谈一下自己的看法：
我是从90年代中期从MIS开始、经历了信息管理系统逐步细化、分化发展的过程：ERP、CRM、PDM...。在最早做项目时，一般是C/S的比较多，项目的开发过骤是：需求分析、系统模型、业务流程图、数据字典、系统实现，其中前三个步骤需要反复几次，定版后才开始设计数据库和编写代码，偷懒时会直接用系统模型来代替业务流程图。在系统实现阶段，一般会分离表现和业务，以便后期进行美化。如果是网络版且需要事务，则会在表现层和业务层之间插入一个网络事务处理层（有时用第三方中间件，有时则自己用DCOM或COM+实现）。
那么，这里的业务是什么呢？我认为，不管是MIS也好、ERP也罢，所谓的系统业务就是数据的存储、组织、处理和呈现的动作和过程，当我们把这些过程的实现划分到一个运行单元中时，就形成了现在所谓的业务逻辑层。
然而，现在很多公司（包括我们公司）在划分三层时，所有的数据处理动作和过程都放到了数据访问层里，业务逻辑层只是一个传声筒，这让我百思不得其解。与同事们讨论，他们说我OUT了，此业务层非彼业务层，是用来耦合表现层和数据访问层的，同为保留了扩展性（比如加上WCF等），数据层者是一个系统的灵魂。我听后羞愧不已，但心底里还是不明不白。如何BLL不叫业务逻辑层了，叫个中间层、耦合层什么的，可能就好理解了。
可惜的是，不管我有多少困惑，业务逻辑层依然叫业务逻辑层，只不过是一个没有了业务逻辑处理过程的业务逻辑层而已。
一个软件或一套系统，其核心和生命就是业务逻辑处理，c#大家都会，sql语句谁都可以掌握，javascript更是一个好玩具。但是，为什么同样的数据库、同样的开发环境、同样功能的系统实现，有的用户赞口不绝，有的却抱怨连天？究其原因，我想，其中的关键恐怕在于对业务逻辑的理解和实现的差异造成的。就如同银行的柜台业务处理系统，到现在AS满天、银光遍地的时代，依然还在使用基于cursor库的字符终端界面，也没见多少操作人员抱怨过什么，因为它满足了用户的业务需求而不是审美需求！
所以，BLL绝对不应该成为一个传声筒，DAL绝不应该包罗所有业务过程，绝对不应该！DAL只负责具体与数据库进行交互，面对数据库资源，完成数据操作动作；而BLL则对DAL中的数据操作动作进行有机组织，面向业务处理单元，实现业务处理（数据操作）流程。
因此，我心目中的三层架构应该是这样的：
DAL：DAO->DAFACTORY->SQLHELPER
说明：数据访问层的实现就是ORM+工厂模式
  DAO数据访问对象，实现数据库资源动作（CRUD）的抽象化和对象化，面向数据库，可以用代码生成器生成。
  DAFACTORY数据访问工厂，是实现DAO中CRUD的具象化的一个工厂。
  SQLHELPER，数据访问工厂指象的基于SQL SERVER的一个实例，真正实现DAO的CRUD。
MODEL：数据实体，实现数据库资源结构的抽象化和对象化，业务简单时可作为DTO来使用，面向数据库，可以用代码生成器成。
BLL：BO（业务对象），根据业务的关联关系和处理流程，调用一个或多个DAO类的方法实现系统的业务逻辑，面向业务单元，不可以用代码生成器生成（很可笑的是，现在大多数代码生成器居然也生成了BLL，如果真的管用，那还需要开发人员干嘛）。
  比如数据访问层有DAO：daoUser、daoUserFavorite，分别对应数据库中的tblUser、tblUserFavorite两个表，前者存储用户的account、password等信息，后者存储用户的favorite等信息，业务需求包括用户登录验证、用户收藏、用户删除等，此时我们可以创建一个boUser类（即User业务管理单元类），它提供了Check、Favorite、Delete等方法，在Delete业务方法中，还存在两个DAO的级联调用，即if(daoUser.delete()==true)daoUserFavorite.delete()；。
UI：该层就不说了。
我的理解不知道是否合理，热情邀请大家交流解惑！


------解决方案--------------------
神马都是浮云。
三层只是忽悠人的嚼头。

------解决方案--------------------
分层的目的是为了适应变化。在传统的程序中，用户界面和数据库访问由单独的开发者设计。

肯定不希望数据库变动或者用户界面变动的时候无序地修改程序。这是把业务逻辑从数据库访问和用户界面分离出来的主要动机。

但是扪心自问，你分层后改变用户界面或者数据库，你的业务逻辑层能不能做到不修改，或者有序修改，如果可以，你的分层是成功的，否则是失败的。
------解决方案--------------------

探讨

------解决方案--------------------
我也认为业务层应该管逻辑处理
如果数据访问层做了,业务层存在意义究竟在哪?

#2楼同志
改变用户界面或者数据库
业务逻辑层修改不修改又能证明些什么


------解决方案--------------------
业务逻辑只要实现一遍,就可以挂接到任何UI平台,
任何不同的数据结构,而不需要修改什么代码

比如说:我实现一个供应商信息管理,
数据库的表无论是Supplier[Id,Name,Code,Fax]
或者是Org[OrgId,OrgName,Description]
都不需要修改业务逻辑的代码,
能导致修改的只有一个原因,就是业务逻辑接口(也就是设计接口)的变化

同样道理,今天UI用asp.net,明天用winform,都使用同一份业务逻辑代码,
并且,如果是MVC的,界面也不需要重新开发,利用视图驱动器自动渲染
------解决方案--------------------
为什么几乎所有的复杂一点的设计都是MVC的,
就在于这种设计模式的高度可重用性,
这一点,在哈勃望远镜的生命历程中表现的淋漓精致
------解决方案--------------------
我分层跟楼主的一样。


------解决方案--------------------
分层的好处，就是为了适应不同数据库，不同UI。

如何分层， 就是要适应不同数据库，不同UI，你们怎么去做呢？ 工厂模式、反射。

怎么分层才是合理的呢？ BLL层要体现逻辑关系， DAL是操作后台数据。

分层真的好吗？ 不好，最终还是要转换为SQL语句。 速度一定是下降的
不好，对于复杂的多表关联， 痛苦

------解决方案--------------------
上学的时候对这个理解一直不是很深刻，感谢lz分享~
------解决方案--------------------

探讨

------解决方案--------------------