有同感
  回复  引用  查看    

大部分同意，我现在开发基本上是界面层+业务层+数据库。
  回复  引用  查看    

不说多的,如果不分层,我见过一个页面有1万多行代码的

你理解不了三层的话,就理解成把代码分成几个"抽屉"来便于管理好了

小项目还好,项目代码一多起来,不分三层来管理会搞死人的,你做过一起才能明白

这些东西一定是要经验的,一定要失败过才能明白...

就说这么多...


  回复  引用    

建议摘要发布。太长啦。
  回复  引用  查看    

如果你想做一个既有B/S又有C/S,甚至Web Service的时候,三(N)层结构就体现了它的价值
  回复  引用    

数据库频繁变动只能说明伟大的需求没做好。
分层显然有优势，可以多个小组并行开发，单元测试，然后组装到一起就行了。
而且可以最大限度避免散弹式修改等等。对维护的有利那就不用多说了。
  回复  引用  查看    

--------------------------------------------------------
@CCTV
我也见过这样的人，我底下的程序人员也用了三层以后一个页面也写了将近6000行代码的。解决这个的方法是提高编码人员的基本素质，而不是三层。

我不是反对分层，而是阐述我在应用了三层后的诸多疑问，希望通过讨论能找到更好的解决方案。


  回复  引用  查看    

--引用--------------------------------------------------
bmrxntfj: 建议摘要发布。太长啦。
--------------------------------------------------------

  回复  引用  查看    

个人感觉，如果大家觉得作项目很费力，那么你的思考的切入点，应该是你的设计和架构做好没有？ 是不是真正做到了，减少依赖，降低耦合度，对修改封闭 等等
  回复  引用    

web开发应用也有的非常非常之复杂,winform应用也有的非常非常之简单.

个人觉得复杂项目一定要用,简单项目无所谓(但刚好用来练手,不然不熟练的东西谁管随便用在复杂项目里面?)
  回复  引用  查看    

其实我觉得几层无所谓，关键是知道到什么地方找什么东西。
  回复  引用  查看    

有感觉

  回复  引用  查看    

@第一控制.NET
一方面对于web用户的需求总是会变动的，网站的改版也越发频繁，祈求用户的需求不会变动是不可行的。

另一方面，“最大限度避免散弹式修改等等。对维护的有利”。虽然有上述优点。不过应用三层和服务器控件后带来的性能损耗是不可避免的，这对用户体验又是一种损伤。。。。。
  回复  引用  查看    

3层是好的,

不然一个页面把 业务\存储数据\其他 等代码都写到一起,是意大利面.

其次,一个操作数据表数据的功能在其他N个页面需要时,不分层只会重复做轮子.

再次,一个操作数据表数据的功能在其他N个页面重复做轮子后,有一天改了某操作数据的逻辑,引发N个页面做手术.改漏了一个页面给客户看到黄色的鸡肠后就会X@#$%^&*!!!

还有,等等等等.....等着你自己去发现.

说白的,我刚开始转到3层时也有你所提的疑惑.不过很快就明白它的好处的了
  回复  引用  查看    

@生鱼片
开始没注意，感谢提醒
  回复  引用  查看    

三层不就为了逻辑跟界面解耦吗，为什么三层了就一定要结合大量服务器控件呢？这两者似乎没有必然联系，如果你不用三层就不需要那么多控件，那用了三层一样可以不用那么大控件。
  回复  引用  查看    

@icewater
这些固然是好的，可以三层真的就万能么？真的就是开发的银弹么？？？
  回复  引用  查看    

我觉得看如何分，如果层次分的好，解决了分布的问题，还是值得的，为了分层而分层，只是图以后代码好改，有复用性，我觉得在某些场合就没必要
  回复  引用  查看    

@第一控制.NET
三层解耦步不仅界面解耦，还有数据和逻辑，但是我感觉依然是没有解开。数据层的修改必然带来逻辑层的修改（最起码目前我是这个样子）。

  回复  引用  查看    

个人认为其分层，就是把不同类型作用的文件分开保存
这样系统出错以后就可以准确找到出错的位置
如果不分层，代码都堆砌在一起，
别人是没办法该你的代码的
分层以后，比较清晰
  回复  引用  查看    

另外三/N层的和服务器控件没任何关系,甚至你可以不用任何ASP.NET自带的控件都可以,界面全部用HTML标记,用FORM提交,用REQUEST.FORM取数据,不过可以用Repeater绑数据,你可以不用实体类,把数据表的数据用DATAREADER读出放到Dictionary<string, string>,再绑,这样比DATSET效率高.比如:
<asp:Repeater ID="Repeater1" runat="server">
<ItemTemplate>
<tr>
<td><%# ((Dictionary<string, string>)Container.DataItem)["UserName"]%></td>
<td><%# ((Dictionary<string, string>)Container.DataItem)["Password"]%></td>
<td><%# ((Dictionary<string, string>)Container.DataItem)["Email"]%></td>
</tr>
</ItemTemplate>

</asp:Repeater>

  回复  引用  查看    

@jillzhang
的确是。。。不过我觉得对于修改频繁的项目标准的三层似乎还是有缺陷，但是如何解决？能否赐教一二。
  回复  引用  查看    

就简单的做个网站而言 确实没什么必要
一个共用数据操作类 就够了.
  回复  引用    

@icewater
这样的方式asp也可以做到。
有的时候也怀疑过asp.net的必要性，难道就是大堆的服务器控件+库？？
后来想想也通了，编程语言就好像武器，asp好比刀，asp.net好比枪，都能杀敌不过是手法不同罢了。
关键是编程方式的变革。。。。。

不过现在讨论的3层，貌似跑题了，呵呵。
  回复  引用  查看    

个人拙见：如果项目比较迷你的话，不一定要分三层，但是数据访问和UI还是要分开，这个好处是很明显的，只不过说对过于简单的业务逻辑的情况，可以抛掉业务逻辑...分层一样可以不用服务器控件，出来的效果应该也不会比不分层的差吧？而对于后台来说，用上ObjectDataSource和GridView等配合，开发速度是非常快的...

  回复  引用  查看    

没有完美的结构，三层确实有缺陷。
  回复  引用  查看    

我觉得分层的好与坏不是绝对的，要看项目的复杂度
楼主说的是有道理的

但是设想一下这样一个应用，
可能同时被Web，各种外部的服务，甚至某些cs或winform的东西使用
其实这样的应用我们经常会遇到，现在web应用，已经不再是一个孤立的个体
对于这样的一个应用，如果不分层，岂不是对应于每个服务和调用方，都要写一套访问的代码？
但是如果分层，那可能只要对应各种调用，写一些高层的逻辑，完全可以共用底层。

所以分层与否，要看做什么应用，总得来说分层还是科学的，但是不是无论什么都分层，就有待考究了！~
  回复  引用  查看    

简单的CRUD操作没有必要分这么清楚
如果业务逻辑复杂，有必要，难道都写在页面cs里面？这样不好测试
UI逻辑也得测，但是web form不行，所以可以考虑用MVP模式
如果数据库基本不改变，dao层可以抛弃了
  回复  引用  查看    

@水言木
的确是这样，我去年熟练应用三层后就对三层有了病态似的追求，凡是项目必定要用设计模式，凡用设计模式基础必定是三层，导致的直接结果就是一年内所有的项目均基于三层。好在我经手的项目就算变动再多都可以如期完成，项目也顺利通过检验。我知道是三层的功劳，但加班同样功不可没^^.

这几天又在做一个新项目，看到快吐了，代码几乎是模板似的，死气沉沉，虽然结构分明，组织良好，但是却第一次反思起这个问题。。。。。
  回复  引用  查看    

同感
有的时候没必要用三层
要喝的好
但谁觉得好了
  回复  引用  查看    

@紫色阴影
在使用三层前也会组织代码，把不同的模块放入不同的命名空间，将不同的功能划入不同的类。这个属于设计人员的最基本素质。
  回复  引用  查看    

首先、三层是否真的像鼓吹的那样便于修改？？？我在项目的进行过程中经常要修改项目的数据库，而每次修改过数据库都非常痛苦，因为除了反射不用修改外，其他的要从实体层一直修改到表现层，层层都要改。
这难道是减耦？？我觉得这依然是强耦合。
--------------------
如何修改，如果对某个表添加字段，各个层需要修改吗？。如果对某个表删除字段，设计不好怎么能怪三层。


其次、三层带来的臃肿是空前的
---------------------
所有的东西在一个地方做难道不是臃肿，把职责分清楚分在多个地方就是臃肿？


再次、抽象。在web应用大多不过是对数据库进行读读写写
--------------------
也不一定吧，salesforce也是基于web，业务逻辑就很复杂了
  回复  引用  查看    

@黑羽飘舞
在使用三层前也会组织代码，把不同的模块放入不同的命名空间，将不同的功能划入不同的类。这个属于设计人员的最基本素质
--------------------------------------------------
恩，如果把业务逻辑分到不同的类，称为xxService类，不就是分出来的一层？
把数据库操作又分到不同的类，不就是数据访问层？

当然三层有很多evil的地方，我也不是完全的赞同
  回复  引用  查看    

认为自己写的各类代码以后都不需要修改,可直接不用分层.否则请还是分层.

另外,如果为了开发快,高性能用存储过程,并把业务也写到存储过程,可以去掉业务层.

再说一下你说的修改了数据层把业务层也要修改,这个是必然的,你的方法都变了,传的参数都变了,业务层要调用变了的数据层借口当然也要变了,除非用一个集合传递参数,如实体类中你加多一个字段,插入因为传的是一个实体类就不需要改业务层,只需改数据层多 INSERT 一个字段而已.

另外,你用3层做了那么多个项目还没体验到它的好处我也无话可说,可以说如果你做一个真正的项目,不分层所带来的工作量肯定比分层的大.

分层用代码生成器解决效率,不见得工作量多了多少,如果你很会合理的设计,各层的代码结构,是可以用技巧去解决分层的弊端的.
  回复  引用  查看    

@紫色阴影
貌似如此，不过很多时候数据访问层完全可以抛掉的。因为数据库是指定好的，并不会有变化。而且随着时间的推移，用户需求的变动，数据库也需要跟着修改。数据访问层就是个累赘了。在数据访问层和逻辑层间耦合还是有的。。。。
  回复  引用  查看    

@icewater
代码生成器我也有写，不过这个是技巧问题。
核心问题还是在于三层的适用性。。。。
  回复  引用  查看    

你一个人写会觉得烦也正常，如果是协作的话不分层你怎么办？要求所有人都从数据到表现都会么？还有，不分层的话，就凭webform怎么做测试？
  回复  引用  查看    

东西是死的，人是活的。
  回复  引用  查看    

严重同意楼上所说的
  回复  引用    

设计模式要根据需求灵活运用，不能生搬硬套
  回复  引用    

建议楼主踏踏实实多实践几年，你这题目可大的很哦，比较吸引人的眼球，少点浮躁和埋怨，多体会前人经验的精髓。
  回复  引用    

软件设计没有绝对的规则，最适用于具体情况就是最好的
  回复  引用  查看    

感觉还是分开好,对维护,测试等等都有好处,缺点嘛,想办法自己克服
  回复  引用  查看    

1、不用三层绝不等于 不分层

2、三层是一个看似简单，但是很不容易掌握的东东。

3、三层（n层）只是分层的一种方式而已，不是唯一！

4、三层不适用于那些数据库频繁变动的项目。

5、用三层在编码之前，至少需要话几个月的时间做设计。

6、lz说的是 web开发，也就是网站，所以请不要说winform的情况。


  回复  引用  查看    

三层不能完全解藕，能完全解藕的东西还不存在，它只能更好的组织你的代码！

三层也不是非要asp。net 来写，用asp 一样能达到效果，看你的代码能力了！

三层不过是解决问题的一种手段，不是治疗百病的灵丹妙药，用不用的好，就完全看你的能力了！！！
  回复  引用  查看    

博客园首页质量是越来越低了。
咳，悲哀啊。
  回复  引用  查看    

我现在的这个项目就用了，对以后维护方便些吧，还有就是约束性的规范了
  回复  引用    

很不认同。。
  回复  引用  查看    

这个问题很无聊,就象是先有鸡还是先有蛋,用不用三层要看程序的复杂程度等一些因素,光说该不该用感觉很无聊
  回复  引用    

说的都是大实话 不是鬼话 呵呵
  回复  引用    

如果要搭个帐篷,是没有必要打地基和设计图纸的
但是盖个高楼能少了这些吗?
  回复  引用  查看    

而三层要结合大量的服务器控件
------------------------
楼主没入门。
  回复  引用    

谁告诉你这些都要用手写的了？

再说数据库老变化，好像和多层体系没有太大关系
任何体系都很难解决你数据库老变的问题

其实使用代码生成器的最好时机不是在开发期而是在
项目运行中，根据不同的变更迅速生成代码、动态生成
代码来直接满足客户要求，或者稍微修改就可以使用

只有逻辑复杂的地方才需要手工进行修改；

如果你的项目到处都是逻辑很复制的那，这个项目绝对有问题；

如果是一个、界面设计不过关，数据库不恰当的项目、项目安排不合理的项目
应用什么模式都是枉然

应用多层架构切忌肝火上升，边设计边开发；

我做多层多年了 省级市级的项目做过几个、没发现楼主的诸多问题


最后我终于看懂了，博主说的根本不是3层而是，简单工厂模式
dal bill idal petshop 那种！这种模式本身就是针对成品的比如
你在 sqlserver 上开发的程序，便于移植到oracle 而且不会出现
使用 orm 哪么大的性能损耗、不过要多写一个 DAL 适合多种
数据平台等，不一定是数据库也可以是xml 或 WebService；

汗到一下；

  回复  引用  查看    

一句话，楼主的经验尚浅，还属于新手阶段！没什么好说的
  回复  引用  查看    

做过大项目的都知道，三层往往还试验不了这些需求。。DZ论坛是学习MVC模式最好的资料
  回复  引用  查看    

你做过复杂点业务的系统就知道了，我现在刚刚经历过了，对分层的好处深有体会。
劝LZ一句，那么多系统用N层构建（业务N简单的不算），并不是吃饱了撑的。
这种文章也真的是名副其实的月经贴，太无聊了。
  回复  引用  查看    

1、其实多层结构并不一定说需要实体类。
现在很多三层结构造成麻烦的最多是实体类部分，个人建议在使用生成和重构工具的情况下才使用实体类模式。
2、三层结构并不臃肿，很多现在的开源和商业组件框架是很有实践价值的，没说什么都要重头开发。
3、读读写写，三层和不是三层都需要，关键在于你如何设计流程，该缓存的缓存，该静态的静态，三层不是为了性能而诞生的，好的结构其实才能真正提高性能，无论它是不是N层。
4、适当的使用服务器控件和绑定技术有利于良好的结构设计，看你的取舍和实际的应用来决定，.net本身就是一个慢一点的东西，如果真是为了一点点服务器控件的差别而不使用它，为什么你还在用.net?
总得来说，其实很多东西是因地制宜，充分利用.net的优势，不要为概念而作架构设计，而是需求来决定架构设计。


  回复  引用    

1、其实多层结构并不一定说需要实体类。
现在很多三层结构造成麻烦的最多是实体类部分，个人建议在使用生成和重构工具的情况下才使用实体类模式。
2、三层结构并不臃肿，很多现在的开源和商业组件框架是很有实践价值的，没说什么都要重头开发。
3、读读写写，三层和不是三层都需要，关键在于你如何设计流程，该缓存的缓存，该静态的静态，三层不是为了性能而诞生的，好的结构其实才能真正提高性能，无论它是不是N层。
4、适当的使用服务器控件和绑定技术有利于良好的结构设计，看你的取舍和实际的应用来决定，.net本身就是一个慢一点的东西，如果真是为了一点点服务器控件的差别而不使用它，为什么你还在用.net?
总得来说，其实很多东西是因地制宜，充分利用.net的优势，不要为概念而作架构设计，而是需求来决定架构设计。

  回复  引用    

个人认为,在要通过业务来决定用什么样的架构,不能一味的乱弹!
  回复  引用    

没有人可以在一开始就对需求完全掌控，做项目，惟一变化才是不变的
--引用--------------------------------------------------
第一控制.NET: 数据库频繁变动只能说明伟大的需求没做好。
分层显然有优势，可以多个小组并行开发，单元测试，然后组装到一起就行了。
而且可以最大限度避免散弹式修改等等。对维护的有利那就不用多说了。
--------------------------------------------------------

  回复  引用  查看    

恩，看楼主的文章来说，是一个人写的代码，这样分层和不分层没有什么意义。
如果是团队开发，而且有专业美工，分层是相当重要的。、
但是我认为，一般3层就够了，我不赞成分很多层。
就像楼上说的那样，关键要提高程序员的素质，而不是一味的找方法。

唉，一提到素质就闹心，有点积累的程序员都去做管理了。
写程序的永远都是毕业1-3年的，苦啊。
  回复  引用  查看    

大部分人分层只是为了分层，根本不懂从设计角度看到的系统层次
  回复  引用  查看    

这定义……Web应用就不能是大型应用了阿？
  回复  引用  查看    

等你什么时候一个数据库要做n个不同的项目的时候，你就会体会到分层开发的好处了。我觉得你对三层架构理解可能觉得petshop就是一个很优秀的三层架构
了，但是我觉得petshop只是一个入门级，从设计角度来说petshop设计的还是比较差的，请不要把petshop等同于三层架构
--引用--------------------------------------------------
我在项目的进行过程中经常要修改项目的数据库，而每次修改过数据库都非常痛苦，因为除了反射不用修改外，其他的要从实体层一直修改到表现层，层层都要改。
这难道是减耦？？我觉得这依然是强耦合。
--------------------------------------------------------
强耦合?那只能说你设计的分层架构不好，一般来说合格的三层架构数据库的修改对项目是几乎没有什么影响的，一般也是重新用点一下代码生成机重新生成一下代码即可，不需要手动修改什么东西。
--引用--------------------------------------------------
其次、三层带来的臃肿是空前的，本来简简单单的表单提交搞的异常麻烦，先要填充实体，期间还有好多数据封装与转换。。。。
再次、抽象。在web应用大多不过是对数据库进行读读写写，而应用三层还要层层分离，设计各种接口，期间还会浪费大量的资源（这就是传说的盘剥？）。本来提交到web的表单都是应该直接对应数据库的，应该是简洁快速的。
--------------------------------------------------------
只能说你还没有体会到数据库操作与表现层分离的必要性
--引用--------------------------------------------------
而三层要结合大量的服务器控件，无疑对资源又是一个消耗，速度会下降，用户体验就会降低，这是个很重的问题。
--------------------------------------------------------
囧，谁说三层要结合大量的服务器控件,有关系吗？
--引用--------------------------------------------------
web应用，并非大型系统
--------------------------------------------------------
google，yahoo，微软的网站都是小系统？



  回复  引用  查看    

杀牛刀有杀牛刀的用处,杀鸡就不要用杀牛刀
任何事物只有在合适的位置才是好的

个人认为,作网站,特别是需求容易变的,
应该两层+工具类
  回复  引用  查看    

企业级web应用与开发。*
  回复  引用    

还是没个结果
  回复  引用  查看    

为了三层而三层，为了模式而模式就这后果。在设计上没有什么绝对的最好的模式，只有相对合适的设计。前人提供的各种设计模式仅仅是面对各种问题时的经验总结而不是规定，如果你用某种设计模式后，发现对当前项目没什么帮助甚至是个累赘，那么只能说明你选错了模式，而不能说这个模式错了。
  回复  引用    

再一次感叹，博客园越来越悲哀了。

或者说什么鸟还都有了，而且还是愿意 喳喳的鸟。
  回复  引用  查看    

三层鼓吹的好处不用说，什么便于修改，易于维护，统一的编程风格等等我就不说了，大家都知道。


我觉得三层的最主要好处是可以工业化生产程序。统一编程风格和肯定是易于维护的，至于修改你说：“其他的要从实体层一直修改到表现层，层层都要改。
”，如果采用三层结构的话你不用代码生成工具吗？如果不用，全是手工写的话确实很麻烦，不过你采用代码生成工具的改了数据库，再生成一下，几秒钟就搞定了所有修改，当然，前提是你的代码都是非常标准的三层结构，而且没有手工改的地方
  回复  引用  查看    

我们做过上千动态页面的web程序，算不算大应用？
  回复  引用  查看    

鼓吹三层便于修改，易于维护，统一的编程风格，这是一个绝对的误导！！

分层的最终目的是：分布式开发！

换句话说：分布式应用最终导致分层结构的出现！……

而便易于维护和统一的编程风格，那只是一个副加好处，而且也是在分布式应用环境中才能得到上述体现。

分层的最终目的是：分布式开发！
  回复  引用    

三层好象跟服务端控件没有什么关系,你不用服务端控件一样可以三层.
  回复  引用  查看    

可以看出楼主所做项目各层的抽象不够合理，因而对分层产生了怀疑。kiler兄弟已经说出了我想说的，所以也懒得赘述了。
  回复  引用    

分层的前提是对各层的抽象，说白了就是抽象成接口，这样各层的改动才不会影响到其他层，没有抽象就分层还不如不分层！
面向对象编程不是对数据库的读读写写，是通过业务对象的各种对象操作来完成系统功能，要这样做的基础是ORM，要是楼主还在通过对数据的添加修改删除来完成功能的话，只能说明楼主还在面向过程编程。
分层和服务器控件没有关系！
  回复  引用  查看    

分层好处多，页面方法调用业务逻辑成，业务逻辑调用数据访问层。减轻耦合度。易维护。
  回复  引用    

--引用--------------------------------------------------
黑羽飘舞: @icewater
<br>这样的方式asp也可以做到。
<br>有的时候也怀疑过asp.net的必要性，难道就是大堆的服务器控件+库？？
<br>后来想想也通了，编程语言就好像武器，asp好比刀，asp.net好比枪，都能杀敌不过是手法不同罢了。
<br>关键是编程方式的变革。。。。。
<br>
<br>不过现在讨论的3层，貌似跑题了，呵呵。
--------------------------------------------------------
从asp到asp.net不仅仅是编程方式的改革吧。
应该是技术得革新啊
  回复  引用    

"速度会下降",那你应该用0101010101010101,这种二进制编程,应用更快些.对于现在的计算机,你所说的性能问题可以忽略了
  回复  引用  查看