为业务逻辑层正名：欢迎大家谈谈如何划分三层架构

关于什么是三层架构，眼下应该算得上是“老少皆知”，在此就不谈了。此贴只想让大家一起讨论一下如何划分三层。我首先抛砖引玉，谈一下自己的看法：
我是从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：该层就不说了。
我的理解不知道是否合理，热情邀请大家交流解惑！