为业务逻辑层正名：欢迎大家谈谈如何划分三层架构关于什么是三层架构，眼下应该算得上是“老少皆知”，在此就不
为业务逻辑层正名：欢迎大家谈谈如何划分三层架构
关于什么是三层架构，眼下应该算得上是“老少皆知”，在此就不谈了。此贴只想让大家一起讨论一下如何划分三层。我首先抛砖引玉，谈一下自己的看法：
我是从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分享~
[解决办法]------解决方案--------------------
我觉得 分层体现的本质就是面向对象的封装 某一层就只负责他要做的事情 其他的一概不知 数据里面柔和了逻辑我觉得就是没有设计的体现
[解决办法]最初的做法是:
把数据从业务逻辑中分离出来;
把数据从视图中分离出来;
接下来:
针对业务逻辑的模型对应的设计视图模型
[解决办法][解决办法][Quote=引用:]
引用:
对于多表关系，我是用视图来解决的，否则，没法使用泛型，而失去了泛型，UI人员就麻烦了。
分层的好处主要是可以实现雁阵梯队式的人力分工和任务安排，不是每一个程序员都精神js（比如javascript类继承、反射、浏览器兼容），也不是每一个程序员都精通sql（比如cte、异步触发器、交叉连接）。
如果业务简单人力少，不分层也罢。
好，现在问题来了，既然你是用视图，你的三层问题来了
如果数据库（你用视图，好像指的就是数据库）的表名，表字段有变化了，
你的视图是不是也要手工去变更，
你怎么让你写的DAL、BLL不用变动就能用呢？
这样子，三层还有用处吗？ 一变全乱！！！！
[解决办法][解决办法][解决办法]要是只有抽象的那部分才被称为代码，那一辈子随便怎么修改都可以说是不修改任何代码。
[解决办法][解决办法][解决办法]不会有料的，要是把料放出来，你就能发现他们话中的漏洞了
[解决办法]其实很简单来着，为啥我们的bil是传声筒，因为我们的开发不是有组织有目的的开发。
因为你是无目的去开发滴，所以你没办法有效面对服务。所以你只好把下面的胶水和剪刀一起提供出去。因为这样可以把责任推给UI的人。UI想干啥自己用胶水、剪刀实现呗。
有目的开发则不同，他只会提供封死的api，外面完全不知道里面是啥，也不用知道里面是啥。所以逻辑才只能在api内部。
[解决办法]没料出来，继续灌水。
当楼主给我们讲多表用视图的时候， 有没有发现，一变全变。 --这是问题，用视图不可取
其实更要命的还在后面， 当要求事务处理的时候，你又会怎整？
假如我更新表1、同时又要更新表2
而就是多表关联+同时多表更新
它会怎样呢？ 三层？？？？？？？？
[解决办法]三层架构确实是维护起来很方便
[解决办法]从JAVA转过来的都应该有这个疑惑，在java中业务逻辑层就是进行处理的，但是在.net中处理放在了模型里面，业务逻辑好像就是一个过渡，为了不让用户页面直接访问数据库。。。
[解决办法]现在国内所谓的“业务逻辑层”不过是数据库逻辑层，所以service直接变成Dao没什么不妥的。
[解决办法][解决办法]路过，凑巧各位大牛在讨论拯救世界，于是乎搬了个小板凳就坐下来了
[解决办法]用户层、应用层、调度层
无论是将美好的用户体验放在浏览器中实现（富客户端），还是在服务器端实现（廋客户端）
这都是用户层的事情
数据结构与业务逻辑是密不可分的。过去因为对数据库的不了解，把数据访问独立开来，这是违背现实的
[解决办法]
十分赞同34楼的说法
[解决办法]
搬个小板凳凑热闹。。
[解决办法]
楼主分析的很透彻！
[解决办法]
给一个三层架构的例子：
我在国内一家电力自动化应用公司做的时候，公司的产品非常注重分层，让我们这些人得益匪浅，全依仗最初的老板技术大牛叉，看看现在的SOA，老板们在90年代初的时候，就已经在我们的产品中实现了。
产品主要是实时接收各类终端设备的数据，然后对数据进行处理、分析，展示分析结果并提供业务执行方案。
DAL:全是以DLL的形式被BLL的模块调用，一类终端设备一个DLL，这些DLL负责接收终端设备的数据，并依据不同设备的规约要求，将“生数据”处理成"熟数据"，生数据就是不同设备自己定义的格式，熟数据就是我们这套系统自己内部定义的通用数据格式，用于与自己的BLL层模块通信。遇到新的一类设备怎么办，写一个DLL即可。但DLL 与BLL层模块的接口永远不变。所有设备通吃。
BLL: 业务逻辑层，对数据进行业务处理，比如有效性校验，系数处理，控制命令处理，通信业务量统计（流量统计、信道统计等），等等。这个模块处理后的数据，准备好为后台使用。这个模块是一个后台服务。
UI:我们自己使用C/S开发的客户端，只在本系统局域网内使用。该UI与BLL通信就是采用的SOA架构来实现。
上述就是一个标准的三层模式，有一天用户心血来潮，说有一个第三方的UI，想利用你们的数据。OK，很简单。我开放我的BLL层访问接口给你。或者某一天，我自己心血来潮，要用WEB方式来监控了我的数据了，你认为我需要改动我的BLL吗？一句代码都不用。
[解决办法]
[解决办法]支持，和LZ做法一致
[解决办法]不错的文章
[解决办法]当别人说“数据层者是一个系统的灵魂”的时候，你就知道其层次了。它的所谓表现层，一定仍然是针对数据库表“增删改查”去编写代码，毫无业务逻辑控制系统的影子，其实自始至终都是过去未搞所谓“三层”时的思路，只不过反而为了包装上“时髦的三层概念”而走形式去了。
在表现层看不出数据层的影子，一个非常直观的系统服务操作具体是涉及3个表、5个表，还是有很多操作根本不涉及表，这是表现层无需去操心的。在业务逻辑层可以用各种方法随意、方便地访问数据库，有人使用ORM、有人使用ADO.NET，只要测试结果都正确就行了。那样的业务逻辑层才是帮助“三层”的。
我们编写程序当然是越简单那越好。分层是一个大型系统长期开发的策略，不应该搞成仅仅是对低级的数据库表增删改查的简单包装。
[解决办法]其实那些人的表现层仍然是针对数据库表的增删改查，只不过这回不是调用sql，而是美其名曰“调用BLL层”了。这种为了三层而三层的封装，劳民伤财，没有必要。
既然无法在设计模式上真正按照业务逻辑系统设计要求去设计，既然满脑子只有一些数据库表，那么就没有必要为了三层而三层，还不如在表现层直接调用数据库的客户端驱动去操作数据库更灵活一些。
[解决办法]讨论的好呀！
[解决办法][解决办法][解决办法]个人理解：
第一层： 数据层一个dll负责返回各种数据集合。
第二层： 业务逻辑一个dll付责处理各种业务的逻辑，满足UI的需要。
第三UI层：只管显示自己的数据，发送用户的操作。
每一层只知道调用，你换数据库那是数据层的事情，你换UI那是UI层的事情。
ps：程序不管分几层，主要的是设计是否对业务有充分的了解，如果了解了业务，分层自然而然也就出来了。
还有就是小的系统还分个鸟的层，直接操作数据以达到最快的目的，在说了目前中国中小软件公司，那有那么多的时间给你搞扩展，实现通用的程序代码等，一个人当俩个人用。
[解决办法]你说的这种开发不需要三层，真正软件只使用三层是远远不够的。可能在你的系统当中封装了良好的回退/撤销/其他编辑功能，你使用三层远远不够。
如果你的客户端需要应付手机/windows PC/其他平台，也许才需要真正的三层架构。
[解决办法][解决办法]个人理解，数据层可以当做持久层来对待，不需要去关心数据库的变动。当我们以业务模型来驱动项目的所有业务流程时，代码就是”变形金刚“，形变思维不变。业务层的设计模式，只不过是为了更好的耦合业务对象间的临界值。
[解决办法]我看很多三层的业务逻辑层都是走过场
如果想真整的三层而且发挥业务逻辑的的特点的话
可以考虑spring.net或者自己开发代理模式的业务访问层来管理事物。
另外：要说的就是本人已经实现代理来管理事物，而且支持分布式事务管理。
数据访问层：永远只是单表操作。事务都是在业务逻辑层。而且不用配置。
而且自己开发了一套orm。支持分布式事务，支持表达式，支持2.0以上版本。不需要反射，
而其支持多种数据库的分布式(MSSQL,Access,MySQL,Oracle)。
[解决办法]楼主的分析很透彻，跟我想的业务逻辑实现也是一样，不过我已经用代理解决了这个问题
现在我的程序的业务逻辑真的很强大了。
数据访问，永远只是单表操作。
[解决办法][解决办法]还以为是挖坟帖呢
以分层的目的来衡量分层是否成功比较好
[解决办法]受教了！
[解决办法]谢谢 楼主分享
[解决办法]如果做三层的，sql的存储过程应该少用或不用！
[解决办法]一般都是在BLL层写逻辑判断，最后得出查询条件，调用DAL取数据的吧，在.net的事件驱动机制里，很多人都把BLL的逻辑处理都写在事件中了，然后在事件中直接调用DAL取数据o(╯□╰)o
[解决办法]以前觉的3层很简单。。
现在觉的3层很模糊。。
好吧。我承认我是来学习的。。
[解决办法]BLL处理业务逻辑 与 UI分离 与DAL 分离，目的就是代码分离各司其职。
[解决办法][解决办法]之前对分层概念模糊，最近才开始看。
[解决办法]夸张点说：
UI：就象网页似的，只显示数据，接收输入的数据，传给中间层。
数据库层：只负责数据的存取，其它的不管（包括存储过程、视图、及简单的多表关联……）。
中间层：负责其他一切操作，包括读取到的数据进行一切处理，及各种逻辑的运算……
[解决办法]看了49楼的例子十分羡慕，这个帖子我看了好几遍了，受益匪浅。觉得自己对三层架构有了一定小小的理解。
我是一学生刚接触编程小半年，在昨天看了帖子以后，我试着把最近做的一下小的项目按我理解的三层架构分层。其实在此出现了一个让我很费解的思想旋窝。
按理说dal的变动应该不会引起bbl的变动，但是如果我的数据库表发生了变化entity肯定要变化，这种情况下如果bbl不变化那么从ui获取到的值怎么封装成对象？如果bbl无法给dal传递对象，那它肯定是要传递sql语句。好吧如果bbl给dal传递的是语句，那么dal的变化肯定要引起bbl的变化。
我也可以在bbl与ui之间增加一个独立的版块用来封装对象，如果这样的话这个版块是什么？这还是三层架构么？
好吧，我是菜鸟，但是我真的想学好编程，各位大牛~~~ 不要拍我哦
[解决办法]按理说dal的变动应该不会引起bbl的变动，但是如果我的数据库表发生了变化entity肯定要变化
1 没事不会变数据库的
2 为什么数据库表发生了变化entity肯定要变化？因为你的数据容器不合理。
[解决办法][解决办法]最近我也在做一个orm
这个orm可以把数据访问和业务逻辑和ui彻底的分开
到做好了时候，开源给大家。
[解决办法]
以前的三层基本都是为了三层而三层，没有太多的实际意义，现在的三层太模糊
[解决办法]
[解决办法][解决办法][解决办法][解决办法]不要为了架构而架构。
[解决办法][解决办法]个人认为业务层基本用不到！！！
[解决办法]貌似用“业务逻辑”这个词过于笼统，如果细分为交互逻辑（比如输入限制，有效性判断等），处理逻辑的话，处理逻辑应在BLL， 而交互逻辑分情况处理，
