分层的意义
平时做具体的项目，除了结构性的东西以外
业务逻辑的大量代码其实都是不能抽象的
而是根据具体的业务，来决定方法的返回值和参数
如果一个业务改变，也很大程度上都会对这两项进行修改

大部分分层例子都是，逻辑层一个函数，数据层对应一个函数
数据层进行SQL语句和参数的组装，逻辑层基本上就是简单的调用数据层
顶多就是把几个数据层的方法组合

这样来说，如果一个业务改变，进而需要修改返回类型和参数的话
两层的代码都需要改，对于维护不是更方便了，而是更复杂了
如果只有一层，改一个地方就可以了

从这个角度来说，分层的意义是什么？

大家讨论下


------解决方案--------------------
也不是所有的程序都需要分层的，

在团队开发中分层比较好分工的，不需要人人都很精通业务，不懂业务的调调别人写好的东西就行了，但是分层在设计的时候要求很高，做设计的人要对业务非常的了解，一旦定下来的东西就很难去修改了


不分层的代码其实很灵活，想怎么改都行，而且你改了对其他的代码基本不会产生影响，能够随时跟上客户的需求，因为更改一个页面，或者某段业务逻辑对其他程序没有影响，但是对程序员的要求就很高了，必须知道很多东西


个人认为分层的好处是让那些刚学会编程的人能很快找到一份工作，虽然工资低一点但那毕竟是有工作了

让经验丰厚的程序员具有更多吹牛的资本，因为增加了很多专业词汇，能把客户吹的迷迷糊糊的最后很开心付账，1层还是3层，或者7层...你想让一个不是很懂程序的客户听了他喜欢那个？


------解决方案--------------------
分层(三层)结构还是有很多优点的，小的系统可能是体现不出来，在电信营帐和银行系统的表现就很明显了，主要表现在：1.优化系统结构，便于维护和管理；2.将客户端与数据库隔离起来，客户端无权限直接访问数据库，大大提高了安全性；3.便于业务（事务）级权限管理；4.可扩展性：若要提高系统性能、处理速度，可增加应用服务器，分担一部分应用服务工作即可，而原来的应用服务器几乎可以不动。5.可以减少网络数据流量和提高数据库响应速度；6.可以节省硬件投资和保护现有投资，要知道大型系统应用的硬件投资都是价格不菲的；7.采用中间件的中间层可以均衡负载，提高系统性能。

楼主所说的“大部分分层例子都是，逻辑层一个函数，数据层对应一个函数
数据层进行SQL语句和参数的组装，逻辑层基本上就是简单的调用数据层
顶多就是把几个数据层的方法组合”，我可以不好意思的说一下，楼主做的项目还不够大，呵呵，大型系统中间层都会用到中间件的，目前用的最广泛的是bea的tuxedo交易中间件，你可以找些这方面的资料看一下！:)
------解决方案--------------------
1、职责划分
2、项目分工
3、标准化
4、专业化
5、减少横向沟通（技术层面）
------解决方案--------------------
事实上，我也一直有此疑问！我的涉及的系统几乎也是如此的设计，但是，DAL 我们设计得尽量的可复用！

然而，另一个角度看，
对于，业务改变？需求变更？那是需求分析没做好，没有挖掘出用户的真正需求，或者潜在需求没有被发现 ....
国内的多数项目开发存在此诟病，频繁需求变更，看似客户的“无理取闹”，更多是作为开发承接方，需求分析没有做到位，没有真正理解业务 ....
------解决方案--------------------
楼主说的 有道理

但是 即时这个业务逻辑只有这个项目或者这个功能用，分出来也有好处的

主要从维护的角度来说，如果全是一个方法搞定 那维护起来可能不好 尤其是换一个人来维护 并且代码臃肿丑陋
------解决方案--------------------
先说分层是耶稣，然后下面一群群的善男信女。

分不开自然有耦合的问题，但这个耦合的问题也要搞清楚，到底是设计失误导致耦合紧密还是这本来就是一个模块。

如果不能解耦，或者LZ不具备解耦的能力。那么分层对于LZ就是没意义的。你解不了耦，你怎么分呢？

为了分层而去解耦，那怎么看也怎么有削足适履的嫌疑，不是么？
------解决方案--------------------
喜欢抽象总是有追求的人的表现。一旦你分层、抽象，就一定会有人跳起来说“性能有问题”，这是一个软件技术进步过程中的公理。许多软件技术都要历经十几年的磨合才能取得比较显眼的地位。

然而，分层这两个字比较空洞，比较容易让人联想和争论。有些人盲目抄袭，这个我们不去发表过多意见。但是小有成就的人很容易将理论“仅仅”做为抽象的原则。这在java阵营、以及设计模式的狂热追随者中尤其常见。当涉及具体项目开发，它认为只要在设计和编码中运用这些原则就行了，对于“灵活运用”的强调容易过多，而一旦给出具体例子则会发现其实非常繁琐和零碎。这些人有时候被称为大师。

不用掩饰我喜欢微软的风格，讨厌java阵营的风格倾向。再有理论造诣的大师，也应该将理论用于开发很多、很具体、傻瓜式自动化工具，而不是仅仅传道而已。

举一个简单的 ORM 框架来持久化对象的例子：

using(Domain db=new MyLocalDomain())
{
汽车 c=new 宝马汽车( "BJ123456 ", "8272372 ");
c.验证库存();
有车的人 p=(有车的人)db.Query <公民> ( "证件号= '1234567890 ');
c.购买人=p;
p.拥有汽车.Add(c);
db.SaveOrUpdate(p); //db会自动保存新创建的对象c。
}

这里，开发 Domain 类型那个工程的时候，并不知道将来需要处理哪些领域对象。如果底层实现使用关系数据库，它可以自动为“宝马汽车（汽车）、有车的人（公民）”两类以及其各个父类、接口创建和维护表结构、外键关联、索引、字段，以及更新、查询。

你的aspx可能根据业务对象的类型上的一个Attribute来动态决定用什么控件展示，那么你的web网站就可以是一个表现层的引擎。

对于缓存系统也是这样。缓存系统设计不是只停留在理论上，不是“只有一个interface而不是成熟的可执行可继承的class”，不是需要每一个自定义对象都自己去写缓存控制代码。实际上，缓存系统并不依赖你的具体业务类型。

任何实际的服务软件产品都是追求这个，而不是仅仅做为理论、“道”被宣扬。

分层理论能够让我们知道下一步该如何“依赖倒置”地设计我们的通用的引擎。分层不是目的，只是一个比较初等的抽象一步。但是这抽象的第一步对于许多人也是比较重要的一步，让人知道原来设计程序不是“想到哪里写到哪里”，而是需要积累很多通用的子系统。
------解决方案--------------------
如果我们设计一个“短信查询业务数据”的小系统，我们肯定不能要求业务对象都必须有哪些接口，我们肯定不能把学校里的那套功能分解理论搬过来，因为业务系统是多年积累的结果，我们的短信查询系统必须去适应原来的上千种具体的业务对象代码，而不是要求重构它们。