爱华网一叶障目
.NET平台上的分层架构（很多朋友称其为“三层架构”），似乎是一个长盛不衰的话题。经常看到许多朋友对其进行分析、探讨、辩论甚至是抨击。笔者在仔细阅读了大量这方面文章后，认为许多朋友在分层架构的理解上存在两个比较大的偏颇：
1.没有从本质角度去理解分层的内涵，而只是了解其表象。
2.对分层架构的理解过于狭隘，只是少数概念，而又不够深入。
许多朋友言“分层”则必称“DAL”、“BLL”、“表示层”等概念，殊不知“DAL”的内部还有“Data Source 架构模式”、“Object-Relational Behavioral 模式”、“Object-Relational Structural 模式”等方面，而其中每个方面下下又有诸多具体模式，如“Data Source 架构模式”又有“Table Data Gateway”、“Row Data Gateway”、“Acitive Record”等等。再说“BLL”，大家都知道“BLL”是“业务逻辑层”，可是什么是“业务逻辑”？“BLL”又可以构建为“Transaction Script”、“Domain Model”、“Table Module”三种模式，各是什么意思？另外，分层也不仅只有“数据访问层”+“业务逻辑层”+“表示层”这一种分法，诸如“服务层”、“持久化层”、“应用控制层”的概念朋友们是否真的熟悉呢。
造成这种现象，我想很大一部分原因是因为大多数.NET平台的开发者（包括我在内）理解分层架构是从Microsoft的PetShop开始的。因为PetShop是官方的Demo，所以被众多.NET开发者奉为圣经，甚至成了.NET平台上分层架构的标准方案。我就曾看到许多朋友在我的博客中留下“分层架构还是PetShop最经典”、“想学分层还是看PetShop吧”、“你这是跟PetShop学得吧”这样的留言。朋友们太崇敬PetShop了，却忽略了一个事实：它仅仅是一个Demo。退一步说，即使它是一个实际应用的项目，这样通过一个具体项目去定义一个抽象概念的方式也是不科学的。
举个例子，一个人不知道“牛”是什么东西，于是请教一位奶牛场管理员，管理员迁出一头奶牛，告诉他：“这就是牛”。从此以后，如果有人问他“牛”是什么，他就会告诉别人“牛”是一种体型庞大，行动笨拙，性格温顺，身上有黑白斑块图案，还有一个好大的咪咪，可以挤奶供人喝。有一天，他听说西班牙有斗牛这项运动，他大惊道：“这怎么可以！牛那么温顺，怎么能用来斗呢！而且牛是用来挤奶喝的啊！”
故事中这个人犯了一个什么错误呢？他把“具体的一头奶牛”和“牛”这个抽象概念给划等号了。他认为牛就是“体型庞大，行动笨拙，性格温顺，身上有黑白斑块图案，还有一个好大的咪咪，可以挤奶供人喝”。殊不知这世界上还有黄牛、水牛、牦牛、斗牛、肉牛等各种牛。他没能做到“透过想象看本质”从而形成抽象概念，而犯了“一叶障目”的错误。
其实，许多朋友之所以对分层架构理解片面或偏颇，是因为与故事中这个人犯了相同的错误。当初，我们不知道何为“分层架构”，于是微软给了我们一个PetShop，说：“看！这就是.NET平台下分层架构的产品。”于是我们“恍然大悟”：“噢！这就是分层架构啊！”。就这样，我们把“分层架构”这样一个内涵和外延都极大的抽象概念和一个具体的Demo划了等号，从而也变成了故事中那个人——我们言分层架构必称DAL、BLL，我们做项目必然依照PetShop方式架构……
我们确实被PetShop“毒害”了。但这不是微软的错，更不是PetShop的错，就像在故事中，我们不能把罪责归咎于奶牛场管理员或那头奶牛。错在我们自己！当微软给我们PetShop时，我们应该在脑中清醒认识到：这是一个分层架构的Demo。而不是理解成了“这就是分层架构”。我们应该钻研、思考，从而抓住分层架构的本质，可是我们没有。与其说我们是被PetShop“毒害”了，倒不如说我们是被自己、被自己那种不良的学习习惯毒害了。我们仅看表象，还是只看了一个表象，然后就冒然对分层架构盖棺定论。而没能透过想象看本质。所以，我们同样犯了“一叶障目”的错误。
以上的错误，笔者也曾经犯过！所以，在下文中，我想和朋友们一起分享一下我在反省自己的过程中，悟出的一些心得体会，希望能借此帮助更多朋友尽快走出“一叶障目”。
洞悉分层的本质
我们可以讨论如何分层，可以讨论分层的利弊，可以讨论分层有没有价值……但在这一切一切讨论之前，我们要先弄清楚一件事：分层的本质是什么？或者说：分层是怎么来的？如果这个问题不明晰，那么我们其他的讨论犹如“浮沙之上筑高台”，再精辟的言辞，如果没有一个牢固的基础，也是站不住脚的。
想要了解分层的本质，就不得不说说分工。分工可以说是劳动生产力上最大的改良，最初分工的好处体现在“比较优势”上，由于各司其职，每个人可以从事其最擅长的劳动，再加上单纯劳动所带来的劳动熟练度提升和减少了更换劳动时的损失，使得劳动生产率大幅提升。然而，随着社会的发展，我们发现某些特殊形式的分工不但可以提高生产力，还有另一些好处！为了理解这些好处，我们举个实际的例子。
今天是六一国际儿童节，一位母亲想给她的女儿买一个奶油蛋糕作为礼物。我们知道，蛋糕需要面粉、需要鸡蛋、需要牛奶等等，还需呀经过一系列复杂的加工和包装过程，但是这位母亲不需要关心这些，她只要去附近的超市直接买就行了。而超市里既没有养鸡场，也没有奶牛场，更没有种小麦的农民伯伯和烘焙蛋糕的工人师傅。这个简单的“买蛋糕”场景，大约可以用下图表示。
图1、制作蛋糕的分工
图1大约说明了一个蛋糕是如何从到达顾客手里的。可以看到，制作蛋糕不是一个单一的劳动，需要许多的分工，如果自底向上看，主要的分工包括：基础物质资料的种植生产、原料加工、蛋糕加工、商业销售。并不是所有分工都如上图这样，上图所示的分工，有一些特点，下面总结一下。
1.下层不知道上层的存在。例如奶牛厂生产牛奶，它不必知道牛奶被拿去做什么，可能被奶油厂收购去做奶油，也可能被雪糕厂收购了做雪糕，也可能被收购去做奶糖，总之，它只管完成自己的职责——生产牛奶，而对于它的上层一无所知。同样，奶油加工厂只管生产奶油，它不必知道奶油被拿去做蛋糕还是做摩卡咖啡。
2.每一层仅仅知道它的下一层（最后一层除外，因为最后一层没有下一层），而不知道另外的下层。例如，蛋糕厂只需知道从面粉厂、奶油厂和鸡蛋厂提取面粉、奶油、鸡蛋就行了，而不必关心面粉是怎么来了、奶油是怎么来的这些问题。
可以说，符合以上两点的分工就是分层架构的思想来源。下面说的稍微正式一点。所谓分层思想，就是这样一种分工：它将系统按不同的职责组织成有序的层次。其中，除最上层外，每一层仅提供若干服务供其相邻的上层使用，但不知道上层的存在；除最下层外，每一层仅调用其临近下层的服务。
所以，所谓“分层思想”，不过是一种特殊的分工形式。而计算机软件架构中的分层思想，是将这一思想应用于软件开发中的特例，而PetShop所使用的“DAL+BLL+PL”的方式，又不过是将这一思想应用于软件开发中的特例的特例。例如，如果某个系统的业务很简单，仅仅是增删改查，那么BLL就没有作用，“DAL+PL”的方式就可以很好完成，这也是很好的分层架构。再如，如果某个系统的业务很复杂，需要先规格化，再做运算，再做整理，那么“DAL+规格化层+计算层+整理层+PL”这种五层架构也是很合理的啊。如果某个系统BLL所暴露的接口太繁杂，那么使用Facade模式在BLL和PL之间加一个“Facade Service Layer”也是很正常的。再者，如果某个系统不需要数据存取功能，例如计算器程序，我们只是想把表示和业务（计算功能）分开，那么就没有DAL了，“BLL+PL”就是合理的。所以，用分层的思想进行架构，本质是“将系统按不同职责组织成有序层次……”这一段话描述的，而不是简单“将系统分成DAL+BLL+PL”，更不是“按PetShop的方式进行架构”。
下面，摘录一段Fowler在《Patterns of Enterprise Application Architecture》中对分层的定义：
When thinking of a system in terms of layers, you imagine the principal subsystem in the software arranged in some form of layer cake,where each layer rests on lower layer. In this scheme the higher layer uses various services defined by lower layer,but lower layer is unaware of the higher layer. Furthemore, each layer usally hides its lower layers from the layers above.
——Martin Fowler, 《Patterns of Enterprise Application Architecture》, P17
大致译文如下：
当我们说一个系统是分层架构的时候，你可以把这个软件想象成一个有很多层的蛋糕的样子，其中每一层放在它的下一层上。较高层使用诸多较低层定义和提供的服务，但较低层并没有察觉较高层的存在。另外，每一层都会对其上层隐藏更低的层。
——马丁 福勒, 《企业应用架构模式》, P17
但是，这里有一点需要声明：虽然说“DAL+BLL+PL”不等价于分层架构，而仅仅是一种实例。但同时我们要清楚的认识到，这个方式之所以如此流行，以至于微软的官方示例都这样架构，是因为对于许多系统，特别是大中型MIS系统，这种架构方式是应该优先考虑的。在这一节中，笔者绝对没有对“DAL+BLL+PL”进行批判的意思，相反，当开发系统时，这种方式可以优先考虑，然后可以根据系统的特点，进行一定得改良。笔者在本节所强调的是：不能把“DAL+BLL+PL”看做分层架构的本质，更不能和“分层架构”这个思想概念划等号。
分层架构的利弊分析
在理解了分层架构的本质的基础上，我们才可以放心大胆的对分层架构进行利弊分析。废话少讲，这一节我们直接切入正题。
分层架构的优点如下：
1.分离开发人员的关注。由于某一层仅仅调用其相邻下一层所提供的服务，所以，只要本层的API和相邻下一层的API定义完整，开发人员在开发某一层时就可以像关注集中于这一层所用的思想、模式、技术，这样，就等同于将分工带来的生产力提高优势引入软件开发。又如买蛋糕的例子，作为超市，只要知道下层API（如何从蛋糕厂获取蛋糕）和本层需要实现的API（把蛋糕销售给客户），就可以制定自己的业务模式很策略计划了，而不必关心如何种小麦、如何磨面粉、如何做奶油、如何做蛋糕等。这样，超市只需进行商业运作，而不必进行产业运作，如此专一，必然提高业务水平。
2.无损替换。想象一下，如果某家奶牛场倒闭了，奶油加工厂也要跟着倒闭吗？当然不会，它可以迅速更换一家奶牛场，因为各个奶牛场都可以实现“提供牛奶”这项服务。再譬如，如果某天国家出台政策，要求所有奶油厂必须从审查合格的奶牛场引进原料，恰好某奶油厂的合作牛奶供应商没能通过审查，那么，只要换一家通过审查的合作就行了。而且奶油厂内部的各个环节一动不用动，因为不同的奶牛场都可以提供“供应牛奶”这个服务。而如果奶油厂自己养牛生产牛奶，一旦遇到这个政策，还得自己去有关部门进行审查，调整相应业务流程，牵一发而动全身。程序中同样的道理，最常听说的可能就是迁移数据库了。
3.降低了系统间的依赖。还是蛋糕那个例子，如果某天蛋糕厂内部换机器了，或业务流程调整了，请问顾客需要关心吗？显然不用，因为顾客只调用超市提供的服务。而超市为顾客隐藏了下面所有产业细节。如果每一个顾客买一样商品，都要了解这个商品从原料生产到成型再到销售的一系列细节，岂不累死了。换做程序中，就如表示层只管调用业务层的服务，至于业务层下还有几层？各种数据是怎么来的？怎么存的？是真实的还是捏造的？都不需要了解，这大大降低了系统各职责之间的依赖。
4.复用。例如，你可以去这个超市买东西，我也可以去这个超市买东西。蛋糕厂可以从面粉厂提取面粉，馒头厂也可以。这样，同样的层就可以为不同的上层提供服务，达到了复用的目的。具体到程序中，例如气象局制作发布了一个“Service Layer”，用于提供天气预告信息。这样新浪、搜狐这些网站可以利用这个服务层提供的服务，制作天气预告页面，QQ也可以利用这个服务在它的聊天工具上添加天气预告，你自己做一个软件需要用到天气预告功能，也可以调用气象台的“Service Layer”。
说罢优点，再来谈谈分层架构的弊端：
1.级联修改问题。这个问题在现实中不好比喻，但在程序中相信很多朋友都明白。例如，一个人事管理系统，本来查看人员信息只能分页查看，而现在，需要增加一个功能：在分页的同时还能分部门。例如，可以查看“销售部的前50个人”，这样，为了这个功能所有层都需要修改。
2.性能问题。本来直来直去的操作，现在要层层传递，势必造成性能的下降。就如在购买蛋糕的例子中。顾客在享受分工带来的便利时，也要承受由于不同层的部门分布各地而造成的蛋糕价格上升，这是因为分层增加了成本，如运输、不同层间部门的协调管理成本等。
纵观以上分析，分层架构有利有弊。这是一定得，世上任何事物都有利弊，所以，把“分层架构捧上天”和“一棍子打死”这两种做法都是不明智也是不科学的。对待分层架构，我们的态度应当是明晰其本质和利弊，然后根据具体情况做出理性的分析和抉择。
从上面的分析可以看出，分层架构可以降低层内变化的成本，而对于API的变化非常敏感。如在级联修改中提到的“在分页的同时还能分部门”的新需求，就是对API进行的变动。API的变动对于分层架构是致命的，修改起来难度非常大。所以，一个简单的判断法则就是：如果您的系统层内频繁变动（甚至整层替换）可能性很大，而API变动可能性很小，就使用分层；而如果API可能会频繁变动，那就要谨慎使用分层架构了。
后面的话
其实，我想说的主要内容，就是前面三节了。不过还是有些话，想和大家唠叨唠叨。
这篇文章，不是一篇技术文章，所以通篇不提技术细节，而只是想帮大家澄清对分层的误解。最近看了很多对分层架构（或三层架构）的探讨，其中以批判居多，有的甚至认为分层就是个没用的垃圾东西。我想，产生这种想法的人，大致经过了以下阶段：听说分层，粗略学习分层、模仿使用分层、用得十分不爽、出来批判。
其实，任何技术都是客观的，都没有错误，错误在人，是人没有正确使用，或没有用到合适的地方。就像我们不能批判刀片不适合劈叉，也不能批判柴刀不适合刮胡子。一项技术想要发挥威力，关键要正确运用，而要正确运用，就需要有深厚的功底，需要我们努力学习，勤于思考。这不是一朝一夕的事情，要有持久的毅力。我们要争取做一个善于用功、善于把握事物本质的人，而不是一个用刀片劈柴、用柴刀刮胡子，然后大骂刀片和柴刀都是垃圾的人。
分层思想从来就不是软件架构中首先提出来的，我们天天上网用到的网络，都遵循OSI七层协议，网络结构的设计是分层思想合理应用的一个典范。另外，在许多其他工程技术领域，分层思想也是很普遍的。所以，不要把分层当成计算机人士甚至软件开发人士独有的能力，相对那些领域，将分层应用于软件架构的技术还很不成熟，还有许多事情等待我们去做。
最后强烈推荐一本书：Martin Fowler的《Patterns of Enterprise Application Architecture》，相信看完这本书，对于分层思想的理解和分层中具体模式的运用决策都会有大幅提高。你会明白，原来分层不是只有“DAL”、“BLL”，原来分层还有怎么多内在的东西。
最后祝大家六一快乐！：）
作者：EricZhang(T2噬菌体)
出处：http://leoo2sk.cnblogs.com
本文版权归作者和博客园共有，欢迎转载，但未经作者同意必须保留此段声明，且在文章页面明显位置给出原文连接，否则保留追究法律责任的权利。
Tag标签: 分层架构,分层
posted @ 2009-06-01 23:02 EricZhang(T2噬菌体) 阅读(4091) 评论(96) 编辑 收藏 网摘 所属分类: 心得体会
发表评论
回复引用
#1楼2009-06-01 23:15 | rad [未注册用户]
看完 不知道还有没有沙发了
想问下 《企业应用架构模式》这本书有中文版么？哪里有卖，貌似我找过好多地方
回复引用查看
#2楼[楼主]2009-06-01 23:17 | EricZhang(T2噬菌体)
@rad
应该是绝版了。我是借学校图书馆的影印版，然后复印的。
回复引用查看
#3楼2009-06-01 23:26 | nicye
文采不错！
回复引用查看
#4楼2009-06-01 23:29 | 坤坤
写得真好
回复引用查看
#5楼2009-06-01 23:30 | haozi0804
1.级联修改问题。这个问题在现实中不好比喻，但在程序中相信很多朋友都明白。例如，一个人事管理系统，本来查看人员信息只能分页查看，而现在，需要增加一个功能：在分页的同时还能分部门。例如，可以查看“销售部的前50个人”，这样，为了这个功能所有层都需要修改。
个人觉得在这个问题上与分层没有关系，是如何实现你的软件结构的问题。
可以考虑把查询和业务领域分开来考虑。
业务层专注于业务本身，而数据的统计查询可以使用其他方式来实现。
回复引用查看
#6楼2009-06-01 23:35 | ocean
我认为经典的三层架构，还是指数据层、业务逻辑层和表现层，至于楼主所说的每一层可能存在的若干的模式，那只是实现方式，不影响层本身的含义。
而像楼主所说的"DAL+规格化层+计算层+整理层+PL"之类的分层方式，跑不出三层的范畴，因为我们可以把中间的三层统归于业务逻辑层，或者说将DAL+规格化层统归于数据层，将计算层+整理层统归于业务逻辑层。
大多数将多层的时候，实际上归根结底还是三层，无非是将每一层再细化一些层而已。
而至于分层的好处，作者分析的确实非常精辟。
对于如何分层，还是要看项目本身，及项目预期的变化。取一个最佳的平衡点来进行。
回复引用查看
#7楼2009-06-01 23:35 | Gray Zhang
其实下层是知道上层的存在的吧，例如底层对于传递进来的参数可以不作校验，因为他信任他的上层已经为他完成了校验的工作，那么他就必然知道他有一个上层，并且这个上层有一项职责是进行参数的校验……
回复引用查看
#8楼[楼主]2009-06-01 23:36 | EricZhang(T2噬菌体)
@haozi0804
如果能预料到所有变化，并预先进行设计，那当然好。但有些变化是我们预料不到的，这里我只是举个例子，例子不是重点，重点是说明“分层架构对API的修改很敏感，往往造成级联修改，这是它的一个缺点。”
回复引用查看
#9楼[楼主]2009-06-01 23:38 | EricZhang(T2噬菌体)
@ocean
呵呵，那么“表示层+校验层+计算层+预处理层”呢？这是我接触到得一个实际架构方式，这个软件是做图形模拟的。这还是“经典的三层架构”吗？
回复引用查看
#10楼[楼主]2009-06-01 23:39 | EricZhang(T2噬菌体)
@Gray Zhang
每个层的职责是被规定的，其中做不做校验就是职责细节规定问题。实践中，下层是不能知道上层的任何细节的。
回复引用查看
#11楼2009-06-01 23:41 | 疯狂年代
写的真不错，欢迎继续分析！
回复引用查看
#12楼2009-06-01 23:41 | Jeffrey Zhao
我觉得，这篇文章最有价值的并不是说明分层问题上，而是在“如何学习和把握问题”方面讲得很清楚！
回复引用查看
#13楼2009-06-01 23:44 | 李永京
很想弄到一本：企业应用架构模式 经典之作
回复引用查看
#14楼[楼主]2009-06-01 23:44 | EricZhang(T2噬菌体)
@Jeffrey Zhao
呵呵，真不愧是老赵。其实确实是这样，相比对分层的理解，我更希望的是朋友们看完这篇文章，能更好的明白“如何学习和把握问题”。
回复引用查看
#15楼2009-06-01 23:44 | 记账本
欢迎继续分析！
回复引用
#16楼2009-06-01 23:49 | feilng [未注册用户]
我只是觉得.net提供了一个基本的足够好的API
有了这个基础的东西，我就在上面可以很好的唱戏了
就好像java一样，我喜欢java本身，不喜欢J2EE
回复引用
#17楼2009-06-01 23:52 | feilng [未注册用户]
怎么唱戏的问题可以从各个方面去学习，不应该局限在.net圈子
回复引用查看
#18楼2009-06-01 23:52 | bills.feng
现在对分层架构有个比较深层次的理解了，消除的好多误区
好文章！
回复引用查看
#19楼2009-06-01 23:58 | 温景良(Jason)
写得不错,分层不分层其实看项目,还有实际应用.分层架构有好处,也有坏处了,很小的项目分那么多层增加工作量.
回复引用查看
#20楼2009-06-02 00:01 | ocean
经典的三层架构，也不意味着所有的程序必须符合这个架构，这更应该说是在做某类程序的时候的一种最佳实践。特别是比较大型的商业程序、LOB之类的。这个不是唯一的架构，如果我们只是写个挖雷的小游戏，有必要搞这么复杂吗。
当年提出三层，也就是数据层、业务逻辑层和表现层，主要也是总结了一般LOB的特点，我们知道LOB必然有数据，比如生产的数据，销售的数据等等，所以我们知道我们要处理的是“数据”（数据层），而如何处理这些数据，当然就是根据我们自己的流程，各种业务规则来处理，这就是（业务逻辑层），当然了，处理完之后，我们肯定要把他们显示出来，这自然就是（表现层）。
至于具体怎么划分，还是要看不同系统的类型，就算一个系统不符合三层架构，我们也不能说是一个不好的架构，因为那个架构可能是在当时的时间，当时的资源，当时的人力和成本下最佳的一种实现。
回复引用查看
#21楼2009-06-02 00:05 | jasonyun
受益良多啊！
回复引用查看
#22楼2009-06-02 00:16 | Astral.Road
对dalfactory造成的毒害更讨厌... 哇咔咔
回复引用
#23楼2009-06-02 00:18 | winter-cn未登陆 [未注册用户]
我觉得PetShop是个不错的三层的例子
就算代码有些问题 恰好说明一个良好的架构可以把质量比较差的代码很好的组织起来
另外 推荐《软件体系结构》 没有读过大学或者大学没读计算机专业或者大学读了计算机专业却没有这门课或者大学读了计算机专业有这门课却没选或者大学读了计算机专业有这门课而且选了但是老师讲错了或者大学读了计算机专业却有这门课而且选了老师讲的也挺好但是没好好学的同学不妨读读
三层其实是个绝对正确的东西 没什么可以批判的余地
回复引用查看
#24楼2009-06-02 00:20 | vincent_赵
非常感谢楼主这么详尽的说明~对分层的认识更进一步~特别喜欢优点和缺点的分析,因为一直都在想这个问题~
对于非MIS系统,例如数据仓库的建立,应该如何合理分层?我一直都是些SQL,重复的代码无法很好的整合，但是SQL的性能是高。。。（我是菜鸟，问题可能有点太模糊了）
回复引用查看
#25楼2009-06-02 00:24 | 碧落
呵呵，从入门时的一塌糊涂，到人云亦云的模仿分层，最后深刻认识分层的价值，进而主动思考每一层的意义，最终能够结合项目实际情况定义出最适合的分层结构，每一步都要付出代价。
----我知道这样做是对的（分层），和我知道为什么这样做是对的（为什么而分层），是两个层次。
回复引用查看
#26楼2009-06-02 00:25 | Selfocus
首先，文笔非常不错，行文流畅，（正反）举例恰当，分析得十分透彻，让俺一口气读完这篇文章，赞一个！
我想在现实生活中，确实有很多人潜意识中把MS的PetShop当成了的标准的分层概念了（包括我），因此，在我接触过的许多中小型项目中，有些业务逻辑不是那么的复杂（或根本谈上不业务逻辑），却硬生生的放一个BLL上去，结果BLL也仅仅是对DAL的简单封装，这是典型的去“套”MS的PetShop模式，呵呵。
博主的文章应该给广大“分层爱好者”提了个醒—如何正确的认识分层、应用分层，在这个问题上，这篇文章应该讲得非常清楚了—你值得收藏！
回复引用查看
#27楼[楼主]2009-06-02 00:48 | EricZhang(T2噬菌体)
@ocean
同意你的观点
回复引用
#28楼2009-06-02 02:57 | turingbook1 [未注册用户]
《企业应用架构模式》我们最近出了英文影印版，欢迎大家前去购买：http://www.china-pub.com/195455
还是那句话，小众的好书，尽快买吧，很容易绝版的。
回复引用查看
#29楼2009-06-02 06:29 | 金色海洋（jyk）
写得实在是太好了，不仅发现问题、提出问题，最重要的是“解决问题”。用自己的心得体会和例子来说明分层的本质，分层的好处，让我们对分层有了更深层次的认识。
我的三层经历：听说三层，粗略学习三层、看别人的项目是如何三层的、感觉十分不爽、自己不用三层。（我用我自己的方式来写程序，不过我感觉我还是用了分层的思想的。）
如果我们都能够像博主这样写文章的话，那就太好了。非常佩服博主，向博主学习！
回复引用查看
#30楼2009-06-02 07:30 | Clingingboy
是的，希望更多的人不要看过petshop以后就讲我要搞框架这些话了.
学习的路很长, petshop只是入门了而已
回复引用查看
#31楼2009-06-02 07:39 | Nick Wang (懒人王)
文采不是一般的好啊，希望大家做技术的时候，都能够多想想技术的适用范围，优点和缺点，而不仅仅是技术本身。
回复引用查看
#32楼2009-06-02 08:20 | Kevin Zou
我的經歷：從直接模擬Petshop三層，造出一個N大的怪物，到懷疑三層，用自認為的最簡潔模式實現，然後發現冗余（重復代碼），於是進行重構，封裝函數，進而封裝類，劃分職責明確的獨立模塊以及其外部接口。於是理解緩存，對象創建，異常，日志等的概念。在系統中明確地確定各支持層或支持代碼所處的位置，以及存在的必然性，合理性和局限性，最終理解系統架構（不過我想隨著更多的項目進行，認識還會不斷的提高，甚至改變）
不過我一直不讚同業務邏輯層和數據訪問層如此重要的地位，對於整個系統架構來說，它們隻是和其它模塊一樣處於一個非常小的平行位置，如果理解了業務邏輯的本質，則騰出更多時間為業務邏輯的非功能性功能作更多的優化，從而有利於軟件的修改和重用。
回复引用查看
#33楼2009-06-02 08:22 | 翔诚
确实不错，受教了
回复引用查看
#34楼2009-06-02 08:33 | 戏水
hao duo si xiang jia a
回复引用查看
#35楼2009-06-02 08:33 | OOLi
不错不错哦
回复引用查看
#36楼2009-06-02 08:44 | flat_peach
先收藏 在看
回复引用查看
#37楼2009-06-02 08:46 | 碧血黄沙.NET
层分的不必太漂亮,但功能要漂亮的实现!!!个人觉得不必刻意在乎层的表现手法.对于很多程序员言必称分层,楼主也不必要这样愤慨哈! PetShop不是"毒药"
回复引用查看
#38楼2009-06-02 08:51 | 雷明
写的不错，受益匪浅！
我要表明的一点是学以致用、触类旁通
不要死盯着一个DEMO就依葫芦画瓢
回复引用查看
#39楼2009-06-02 08:52 | 雷明
至于PETSHOP4.0中本人觉得在中小型项目里面那个DALFactory反射没什么太大作用，还增加代码量
回复引用查看
#40楼2009-06-02 09:04 | 阿鹏
身上有黑白斑块图案，(还有一个好大的咪咪)哈哈，这句好。
牛的例子举的好。:)
回复引用
#41楼2009-06-02 09:05 | zzzzz [未注册用户]
@Selfocus
--引用--------------------------------------------------
Selfocus: 首先，文笔非常不错，行文流畅，（正反）举例恰当，分析得十分透彻，让俺一口气读完这篇文章，赞一个！
我想在现实生活中，确实有很多人潜意识中把MS的PetShop当成了的标准的分层概念了（包括我），因此，在我接触过的许多中小型项目中，有些业务逻辑不是那么的复杂（或根本谈上不业务逻辑），却硬生生的放一个BLL上去，结果BLL也仅仅是对DAL的简单封装，这是典型的去“套”MS的PetShop模式，呵呵。
博主的文章应该给广大“分层爱好者”提了个醒—如何正确的认识分层、应用分层，在这个问题上，这篇文章应该讲得非常清楚了—你值得收藏！
--------------------------------------------------------
的确，刚研究的时候我也是硬生生的来个bll。
回复引用查看
#42楼2009-06-02 09:09 | kkun
分析得不错,不过大部人也并非你想像得那样没有理解"分层的本质"
不过文章还是不错的说,一定会有粗浅的理解和深刻的理解同时存在的,辛苦了
回复引用查看
#43楼2009-06-02 09:15 | kiler
文章写的很好，很有教育意义。
现在园子里很多人对三层主要是以下两个观点。
1.petshop就是三层架构，petshop写的很好，所以我们的开发架构必须完全按照petshop来，如果用的不爽，那是没有掌握三层的精髓，微软写的东西就是真理，不可能错的，一定要坚定地使用petshop的模式。
2.petshop就是三层架构，petshop写的不好，我用的很不爽，所以三层架构也是不好的，软件开发没有必要分层，分层多此一举，浪费时间。
回复引用
#44楼2009-06-02 09:21 | justin.ma [未注册用户]
纯属空谈,少点理论多点实践吧~~~
回复引用查看
#45楼2009-06-02 09:27 | 八一精神
读起来很流畅。
赞一个。
回复引用
#46楼2009-06-02 09:30 | yp [未注册用户]
精辟！太精辟了，文章中用到的奶牛和蛋糕作比喻更加形象的描述了3层架构。
顶！！！！！！！！
回复引用查看
#47楼2009-06-02 09:30 | kiler
我对lz几个观点的看法
1.分离开发人员的关注。
分层的本意确实是这个目的，确实有很多经典的分层架构体现了这个目的，但是我觉得在我们的实际操作过程中很难达到这个目的，首先，想要分出完美的层次结构很难，分层这个东西不是一般人就能分的很完美的，到头来还是会多多少少的存在一些跨层依赖的东西，所以没法分工，还有一个最重要的问题就是开发效率问题，一个模块分几层，几个人同时开发，软件出了问题，谁负责修改，如何界定那个一个层出了问题，最终问题就是大家一起踢皮球，降低生产效率。
1.级联修改问题。
这个问题本质是源于分层的不合理，为什么会级联修改？说到底还不就是分层分的不好，有跨层依赖。网络七层协议里面如果修改传输层和网络层会对物理层有影响吗，不会啊，为什么？人家分层分的好。
2.性能问题。
性能说白了就是多几层调用，这个东西的性能损失微乎其微，基本上可以不考虑。
回复引用
#48楼2009-06-02 09:31 | yp [未注册用户]
@justin.ma
你才是垃圾，楼主这么幸苦写的这么好，你瞎了眼！
回复引用查看
#49楼2009-06-02 09:32 | 金色海洋（jyk）
@kiler
我觉得还有其他的观点的呀。
比如：petshop就是一个demo，demo好不好无所谓，只要我们能够透过现象看本质就可以了。
字典，汉语词典，在字典里面可以找到字的解释，在词典里面可以找到词语、成语的解释，我们写文章的时候，可能会去翻翻字典，但是文章和字典完全是两码事，虽然里面都是文字。
字典里面要包含绝大多数文字的解释，但是文章里面使用哪些字，哪些词没有什么规定的。又不是说我们写文章也要把所有的汉字都用上吧。
在我看来 Petshop就好像一本“字典”，他告诉我们在.net里面我们可以使用哪些方式来实现哪些需求，达到什么样的效果。
至于在具体的项目里面使用哪些，这个就没有硬性的规定吧。
回复引用查看
#50楼2009-06-02 09:39 | kiler
@金色海洋（jyk）
关键是petshop是一个比较差的字典，上面错字很多，你用这样一个字典查出的东西没有啥实际意义。
我也没说开发必须用分层，每个人每个公司都有自己的开发习惯，没有必要强求必须使用某种方式开发，但是不能因为petshop不好从而推论出分层不好。
回复引用查看
#51楼2009-06-02 09:48 | 小龙3
金色海洋（jyk）
不仅发现问题、提出问题，最重要的是“解决问题”。
顶！！！！！！！
回复引用查看
#52楼2009-06-02 09:53 | Mainz
言语犀利，三层架构还是4层、5层多层架构的问题，要根据项目需求和规模因地制宜，小项目高性能的可能一层就好了。
回复引用
#53楼2009-06-02 10:00 | Genius_Zhang [未注册用户]
<企业应用架构模式>大家如果不介意看电子书的话，园里的兄弟早有提供下载了，是中文版的
http://www.cnblogs.com/kiler/archive/2007/06/28/798667.html
回复引用
#54楼2009-06-02 10:08 | xiaoql [未注册用户]
感觉很多时候程序员自己都不知道为什么要分层，导致分层泛滥。什么项目一上手就是分3层、5层。。
真正分层的意义在于隔离变化。你的系统根本都不会变何必分层呢?
回复引用
#55楼2009-06-02 10:09 | xxxxxxxxxxxxxxxxx [未注册用户]
分析利弊有个错别字哦～～
性能问题的最后一句：根绝 -> 根据
回复引用查看
#56楼[楼主]2009-06-02 10:12 | EricZhang(T2噬菌体)
@xxxxxxxxxxxxxxxxx
已改正，非常感谢！！！
回复引用查看
#57楼2009-06-02 10:15 | Json Zheng
我们应该根据实际的情况采用合适的模式，而不并一定要采用3层模式，
呵呵，现在很多人都把微软的PETSHOP模式生搬硬套，这样有时会得不偿失。
回复引用查看
#58楼2009-06-02 10:24 | 炭炭
分层的一切即为了 OCP。
回复引用查看
#59楼2009-06-02 10:30 | 中华小鹰
好文章，好文章。
回复引用查看
#60楼2009-06-02 10:53 | Run.
很好的文章，受益匪浅，谢谢分享。
回复引用
#61楼2009-06-02 10:55 | cicilool [未注册用户]
@Gray Zhang
我认为你的理解还是有点偏颇。
下层的参数，只是他自己的一个规范而已，是假设调用者（上层）的参数符合要求，至于验证，那是调用者自己的责任。
回复引用查看
#62楼2009-06-02 11:03 | 小菜梦想成大鸟
好文章，赞一个。另外，没有绝对的好与不好，适合自己实际的应用就好。
回复引用查看
#63楼2009-06-02 11:15 | stg609
蛋糕的比喻很贴切~
回复引用
#64楼2009-06-02 11:15 | 我也是路过 [未注册用户]
要是每个在校的学生都能有你一半的态度和水平，那我们的软件有希望了。
最近超级郁闷,由于业务变得更加复杂，我把Transaction Script变为DomainModel 结果经理说"你的代码风格有所下降阿，连公司的XX都没看懂你的代码",xx是元老，吐血.......
不喜欢你那张非主流一般的照片。
回复引用
#65楼2009-06-02 11:30 | cicilool [未注册用户]
@kiler
关于踢皮球的问题，我觉得很好界定责任，测试好就ok了啊，谁的没通过测试，问题就出在谁那；
关于级联修改的问题，七层协议，不是一个很好的例子，它只是对上层进行包装而已，至于包装的豪华不好豪华，还是由简单包装改成豪华包装，这和分层里面的修改不是一个概念吧；
关于性能问题，损耗肯定是有的了，不过现在的硬件发展这么快，从应用的角度来讲，一般不是太大的问题
回复引用查看
#66楼2009-06-02 11:40 | 夢龙
我很喜欢看LZ的文章.
回复引用
#67楼2009-06-02 12:04 | gihelo [未注册用户]
实际就像我在不同的博主上留的言。实际的区别只是看你把眼睛盯在那里了，如果你是OOA,OOD你的眼睛应该在 “正真的商业对象”上，如果你眼睛在“正真的商业对象”上，你就是不分层也分层了。现在问题就来了，现在为啥大多数人都不理解分层，原因只是大部分人都只是OOP刚入门，而OOA，OOD的概念完全不知，他们的眼睛基本只关注数据库的结构，去探讨到底哪个ORM更好，那个框架更好，而没有真正把眼睛放在“商业对象”上面。
回复引用查看
#68楼2009-06-02 12:28 | kiler
@cicilool
测试工作量成倍增长，以前只需要测功能，现在连接口都要测了，你觉得有多少公司有能力这么细致的去测试。
回复引用查看
#69楼2009-06-02 12:47 | 李亚
@EricZhang(T2噬菌体)
现在书店里又有影印版的。
回复引用查看
#70楼2009-06-02 12:55 | 麒麟.NET
--引用--------------------------------------------------
EricZhang(T2噬菌体): @rad
应该是绝版了。我是借学校图书馆的影印版，然后复印的。
--------------------------------------------------------
我记得以前学校的图书馆里是有中文版的
回复引用查看
#71楼2009-06-02 13:03 | kiler
《企业应用架构模式》应该是绝版了，估计只有图书馆有借了。
还好有一本中文版原版。
顺便说一句，英文影印版真是贵，啥都没翻就标79，服了。
回复引用查看
#72楼[楼主]2009-06-02 13:03 | EricZhang(T2噬菌体)
@麒麟.NET
有中文版。不过我借的影印版，呵呵。感觉北航图书馆书还是挺全的。
回复引用查看
#73楼2009-06-02 13:13 | 浩子.Wu
回复 引用 查看 #7楼 2009-06-01 23:35 | Gray Zhang
其实下层是知道上层的存在的吧，例如底层对于传递进来的参数可以不作校验，因为他信任他的上层已经为他完成了校验的工作，那么他就必然知道他有一个上层，并且这个上层有一项职责是进行参数的校验……
个人认为这个与知道不知道没有关系，这可以是一个约定的协议。上层按照约定的协议给下层东西，是不是经过业务校验可以让上层去考虑，下层只考虑你传过来的参数是否符合约定的协议，是否合法，是不是合理（业务）就可以不用关心了。就这个层面来说下层可以不知道上层。
回复引用查看
#74楼[楼主]2009-06-02 13:18 | EricZhang(T2噬菌体)
@浩子.Wu
正解
回复引用查看
#75楼2009-06-02 13:22 | 麒麟.NET
--引用--------------------------------------------------
EricZhang(T2噬菌体): @麒麟.NET
有中文版。不过我借的影印版，呵呵。感觉北航图书馆书还是挺全的。
--------------------------------------------------------
呵呵，没错，以前重构和.NET框架程序设计者两本书常年被我霸占。
// 我们是校友：）
回复引用查看
#76楼[楼主]2009-06-02 13:33 | EricZhang(T2噬菌体)
@麒麟.NET
呵呵，我知道我们是校友啊。以前记得你说过一次
回复引用查看
#77楼2009-06-02 13:55 | super_yu
《企业应用架构模式(中文版)》csdn下载
http://download.csdn.net/source/324253#acomment
回复引用查看
#78楼2009-06-02 14:10 | 石牌村夫
写的很好
回复引用
#79楼2009-06-02 14:31 | fishfishku [未注册用户]
看来CNBLOGS是真的不行了
回复引用查看
#80楼2009-06-02 14:41 | itzsl
讲的不错，赞一个
回复引用查看
#81楼2009-06-02 14:54 | kiler
@fishfishku
这里不行，其他地方更差。
回复引用查看
#82楼2009-06-02 15:01 | Reginald
分层的最大好处是关注点隔离， 每一层做好自己该做的事就行了
至于底层对上层传来的参数做不做检测，则是一种合约变成， 假定数据在传入之前就已经做过处理 这是pre-constraint
回复引用查看
#83楼2009-06-02 15:50 | 温故知新
对分层的理解又加深了，感谢楼主
回复引用
#84楼2009-06-02 15:58 | Ric12345 [未注册用户]
级联修改问题，恰恰是没有分层的问题，BLL和DAL耦合的体现，如果DAL和
BLL能够分开，那么只要处理BLL就够了，DAL根本不需要改动
回复引用查看
#85楼2009-06-02 16:03 | ddda
好文章，进一步理解了三层，同时提醒自己对一项技术能给把握住问题。
回复引用查看
#86楼2009-06-02 16:35 | 弹着钢琴设计
不错！
看了你的文章，发现编程是如此的美好和有趣！
楼主又提起我的热情来啦！
回复引用查看
#87楼[楼主]2009-06-02 18:07 | EricZhang(T2噬菌体)
@Ric12345
没有那么绝对的。我在做东西中，觉得最要命的就是某数据表需要增加一个字段，这时往往要从底改到顶。。。
回复引用查看
#88楼2009-06-02 18:16 | pxuan
no bad
回复引用
#89楼2009-06-02 22:07 | kevinl [未注册用户]
通篇文章没看到有什么出彩的地方，咋那么多恶心吹捧的回复呢？
回复引用查看
#90楼2009-06-02 23:45 | Leem
应该说petshop给了一种最常用最经典的分层架构参考，到少让初学者找到了入门的捷径。
回复引用查看
#91楼2009-06-03 00:11 | basibasi
总结的不错，看好你哦
回复引用查看
#92楼2009-06-03 10:33 | Asidy
珍藏了
回复引用查看
#93楼2009-06-04 09:32 | 云淡风轻-.net
不错了
回复引用
#94楼2009-06-06 12:44 | 题目不好 [未注册用户]
不能说是被PETSHOP毒害
PETSHOP 本身并没错
再一个 微软 实践模式团队 出的什么时候实践2.0 的那个PDF
大家应该啃一啃 不知道有没有翻译过来的
回复引用查看
#95楼[楼主]2009-06-06 12:52 | EricZhang(T2噬菌体)
@题目不好
你一定只是读了个标题，没有读文章吧，连略读都没有。我在文章里有如下的话：
"我们确实被PetShop“毒害”了。但这不是微软的错，更不是PetShop的错，就像在故事中，我们不能把罪责归咎于奶牛场管理员或那头奶牛。错在我们自己！"
"与其说我们是被PetShop“毒害”了，倒不如说我们是被自己、被自己那种不良的学习习惯毒害了。"
后一句话还是高亮表示的。
另外，注意我标题中“毒害”二字加了引号，您应该能明白是什么意思吧。
回复引用查看
#96楼2009-06-06 22:30 | abruzzi
很不错，比较深入。petshop, petstore之类的拿来研究的话，确实可以学到不少东西，不过如果照搬来做项目设计，那就有问题了。
