三层与养猪，加入自己的理解。

 数据库好比猪圈 ，所有的猪有序地按区域或编号，存放在不同的猪栏里。

这个比喻数据库。社会的分工，让买金锣的小卖部不用和猪打交道。 小卖部就是呈现给我们火腿肠的WEB（显示层或表示层）。

那么小卖部只与金锣公司打交道。金锣公司的内部员工要经历从养猪到杀猪，到制成火腿。这么多工序。

为了更好的分工配合。肯定要分部门，

用来 养猪的部门，专管猪圈，抓猪送给杀猪部门。（DAL） DBUTITLITY 

 

用来杀猪的部门，天天杀猪制成肉，送给 制火腿的部门。（DAL）  抽象工厂，

为什么杀猪也是DAL。因为要统一制成肉块（Model），火腿部门才可以根据不同需求做火腿还是做腊肠。

但是他只负责制成肉块。不管你后来做成任何东西。我只把肉块提供给你就好了。

所以这里。  DAL 层中没有逻辑  是最棒的。

 

用来制火腿的部门，专管拿肉做火腿。（BLL）

 

这样专门抓猪、杀猪的就专门和猪圈打交道。

 

而其他的东西，它不需要去管。他不需要去管在BLL中（处理）成火腿了还是水饺了。  所以这里。  DAL 层中没有逻辑  是最棒的。

 

而如果BLL（处理逻辑）的有做火腿的，有做水饺的，做火腿的用白猪，做水饺的用黑猪，那么他们吩咐给专业的DAL层就可以。所以BLL层最好不要直接操作数据库。

 

1.因为，BLL层对杀猪 的 猪肉的颗粒程度，块的大小。要求不同。DAL层就要根据命令去杀猪。这个根据命令（或开发环境）去杀猪（抽象工厂   - ------对应数据库，对猪圈的不同的要求SQL还是EXCEL  , 并且他们最后都提供了杀猪的方法。 ）的功能就独立出来做一个抽象工厂功能。如果天天需求不同的命令“杀不同的猪，那么这个抽象工厂功能就可以不断的重复使用了。如果只是偶尔的话，那就没必要独立了。

2.DAL杀猪的过程还有个问题。杀猪的工作太繁重。最好能够有个打下手的，专门帮忙抓猪。所以，杀猪（抽象工厂）的通过BLL的命令。经过自己的理解，打电话给养猪厂的抓猪的，让抓猪的把猪送来，

 

这里BLL命令。我要“一头”，“黑色”的“美国老母猪”。因为BLL就是个传话的，这个母猪肉做水饺还是包子，他也不知道。

 

那么杀猪的就想，哦，“美国猪”都在“SQLSERVER”那个猪圈里面，不再EXCEL那个猪圈里面。

 还有。要“一头”，不是要“十头“，那我就不用”十头“的方法了。用”一头的方法“来杀就行了。 ”十头“用切割机。”一头“用杀猪刀。

 

把想法转告给抓猪的。

 

抓猪的也根据”杀猪“的"，“美国猪”都在“SQLSERVER”那个猪圈" 要求，去抓猪。

并根据要“一头”，不是要“十头“，的方法。去抓猪，并送去“杀猪场”，因为“一头”和“十头”返回的数据集不同。采用的“交通工具”和“容器”也不同。

而且，BLL层也不一定非得要用DAL层。因为，BLL还可以有其他的功能。例如，某天加班。所有BLL的员工不杀猪，都去做火腿装箱。那么就没有用到DAL了。

 

以上的BLL层指的是三层中的逻辑处理层。 下面将的是动软生成的工厂模式的  BLL。

+++++++++====================================

 动软 三层中，抽象工厂的DAL层，虽然到最后SQLSERVERDAL层把数据取出来的方式有很多种。但是这都不是处理逻辑。是抓猪的方法。是针对数据的最底层的操作。

 

而BLL层中虽然看上去都是调用的DAL---SQLserverDal的方法。可是，真正的添加处理逻辑时也是把它写进到BLL里。增加一个方法。用于做处理。

 

更何况，这样来看。动软的三层，其实就是一层，如果说MVC是个模型，那么整个三层中的MODEL是M。V是表现层。C是分为处理逻辑和数据库连接。

 

动软的三层在BLL时其实是调用的DAL--SqlserverDAL。如果我们不在BLL中添加其他方法。其实本质上。这个BLL是DAL的一部分。虽然名字叫BLL。只是抽象工厂模式下，应用DAL的一个封装。仅此而已。对应的咱们自己扩展的应用逻辑DBUTILITY 类库和WEB项目中的后台才是我们的处理逻辑。

 

而且，动软三层在WEB中后台逻辑的引用是调用 BLL（虽然名字叫这个）和Model。MODEL我就不解释了。 BLL。在这里使用时，实质上是做一些数据操作。ADD.UPDATE.DELETE.GETLIST（）类型的这些方法。

 

因为，这样看。BLL层只是我们做火腿的去拿猪肉的一个窗口。 dal把猪肉放在各个窗口里。我们去窗口拿猪肉。BLL里的方法其实就是我们去DAL定好的A窗口里拿小块的猪肉。还是去DAL定好的B窗口里拿大块的猪肉。 BLL层就一个接口。

 

如果把这个过程看作是菜市场买肉。

就是。你通过嘴（BLL）告诉 卖肉的，我要（几斤）（哪个方法)肉， 然后卖肉的去根据你的要求 去割肉。卖肉的才不知道你要做水饺还是包包子类。

 

那么你能说 ： “去买肉”这个动作 本质上是处理逻辑吗？   

 

当然不是，它只是一个接口。 是 数据读取和 处理逻辑的“衔接”。而之后的“打肉馅---包肉包--蒸熟”才是你的处理逻辑流程。

 

它根本不配叫BLL啊。它不配。误导啊。误导啊。

 

动软就一个瞎包

所以。动软就一个瞎包。

它就一个瞎包。

 

================================================================================

下面不是动软的了。
DAL 好比是屠宰场 ，把猪从猪圈取出来进行（处理）屠杀，按要求取出相应的部位（字段），或者进行归类整理（统计），形成整箱的猪肉（数据集），传送给食品加工厂（ BLL ）。本来这里都是同一伙人既管抓猪，又管杀猪的，后来觉得效率太低了，就让一部分人出来专管抓猪了（ DBUtility ），根据要求来抓取指定的猪。
BLL 好比食品加工厂 ，将猪肉深加工成各种可以食用的食品（业务处理）。
Web 好比商场 ，将食品包装成漂亮的可以销售的产品，展现给顾客（ UI 表现层）。

l 猪肉好比 Model ，无论是哪个厂（层），各个环节传递的本质都是猪肉，猪肉贯穿整个过程。

l 通用类库 Common 相当于工人使用的各种工具，为各个厂（层）提供诸如杀猪刀、绳子、剪刀、包装箱、工具车等共用的常用工具（类）。其实，每个部门本来是可以自己制作自己的工具的，但是那样会使效率比较低，而且也不专业，并且很多工作都会是重复的。因此，就专门有人开了这样的工厂来制作这些工具，提供给各个工厂，有了这样的分工，工厂就可以专心做自己的事情了。

当然，这里只是形象的比喻，目的是为了让大家更好地理解，实际的情况在细节上会有所不同。这个例子也只是说明了从猪圈到商场的单向过程，而实际三层开发中的数据交互是双向的，可取可存。不过，据说有一种机器，把猪从这头赶进去，另一头就噗噗噜噜地出火腿肠了。如果火腿肠卖不了了，从那头再放进去，这头猪又原原本本出来了，科幻的机器吧，没想到也可以和三层结构联系上。以上只是笑谈，不过也使三层架构的基本概念更容易理解了。
上面谈了那么多，有人会问，我直接从数据库取出内容直接操作不可以吗？为什么要这么麻烦地用三层架构呢？三层架构到底有什么好处呢？
不分层，当然可以，就好比整个过程不分屠宰场、加工场之类的，都在同一个场所（工厂）完成所有的活（屠杀、加工、销售）。但为什么要加工厂和商场呢？因为当规模比较大的时候，管理起来就会变得非常复杂，这样的养殖方式已经无法满足规模化的需要了。并且，从社会的发展来看，社会分工是人类进步的表现 。社会分工的优势就是让适合的人做自己擅长的事情，使平均社会劳动时间大大缩短，生产效率显著提高。能够提供优质高效劳动产品的人才能在市场竞争中获得高利润和高价值。人尽其才，物尽其用最深刻的含义就是由社会分工得出的。

 

软件开发也一样，

做小项目的时候，分不分层确实看不出什么差别，并且显得更麻烦啰嗦了。

 

但当项目变大和变复杂时，分层就显示出它的优势来了。所以分不分层要根据项目的实际情况而定，不能一概而论。