110,533
社区成员
发帖
与我相关
我的任务
分享web开发应用三层构架真的有必要么
web开发应用三层构架真的有必要么 请注意讨论的前提：web应用，并非大型系统
说来也用三层构架（以下简称三层）开发ASP.NET web系统有些时日了，经手大大小小的项目也有很多。
从初识三层的满腹疑问，再到学习三层时的激情，再到应用三层成功开发时的成就感，直到现在满腹的疑惑。
我们应用三层开发web应用是否真的有必要？
三层鼓吹的好处不用说，什么便于修改，易于维护，统一的编程风格等等我就不说了，大家都知道。
现在我来说说三层的坏话。
首先、三层是否真的像鼓吹的那样便于修改？？？我在项目的进行过程中经常要修改项目的数据库，而每次修改过数据库都非常痛苦，因为除了反射不用修改外，其他的要从实体层一直修改到表现层，层层都要改。
这难道是减耦？？我觉得这依然是强耦合。
其次、三层带来的臃肿是空前的，本来简简单单的表单提交搞的异常麻烦，先要填充实体，期间还有好多数据封装与转换。。。。
再次、抽象。在web应用大多不过是对数据库进行读读写写，而应用三层还要层层分离，设计各种接口，期间还会浪费大量的资源（这就是传说的盘剥？）。本来提交到web的表单都是应该直接对应数据库的，应该是简洁快速的。
最后、对于web应用用户体验是最关键的，而三层要结合大量的服务器控件，无疑对资源又是一个消耗，速度会下降，用户体验就会降低，这是个很重的问题。
目前就想到这些，欢迎讨论。如果有好的方法请不吝赐教！
说来也用三层构架（以下简称三层）开发ASP.NET web系统有些时日了，经手大大小小的项目也有很多。
从初识三层的满腹疑问，再到学习三层时的激情，再到应用三层成功开发时的成就感，直到现在满腹的疑惑。
我们应用三层开发web应用是否真的有必要？
三层鼓吹的好处不用说，什么便于修改，易于维护，统一的编程风格等等我就不说了，大家都知道。
现在我来说说三层的坏话。
首先、三层是否真的像鼓吹的那样便于修改？？？我在项目的进行过程中经常要修改项目的数据库，而每次修改过数据库都非常痛苦，因为除了反射不用修改外，其他的要从实体层一直修改到表现层，层层都要改。
这难道是减耦？？我觉得这依然是强耦合。
其次、三层带来的臃肿是空前的，本来简简单单的表单提交搞的异常麻烦，先要填充实体，期间还有好多数据封装与转换。。。。
再次、抽象。在web应用大多不过是对数据库进行读读写写，而应用三层还要层层分离，设计各种接口，期间还会浪费大量的资源（这就是传说的盘剥？）。本来提交到web的表单都是应该直接对应数据库的，应该是简洁快速的。
最后、对于web应用用户体验是最关键的，而三层要结合大量的服务器控件，无疑对资源又是一个消耗，速度会下降，用户体验就会降低，这是个很重的问题。
目前就想到这些，欢迎讨论。如果有好的方法请不吝赐教！
...全文
请发表友善的回复…
发表回复
天乐 2009-09-25
- 打赏
- 举报
对于一个项目而言，没有最好的，只有最合适的
在需求满足度，开发进度，成本，易维护性，易扩展性，可复用性上，总是要综合选取一个平衡的方案
完美的解决方案从来就不存在
在需求满足度，开发进度，成本，易维护性，易扩展性，可复用性上，总是要综合选取一个平衡的方案
完美的解决方案从来就不存在
amdgaming 2009-09-24
- 打赏
- 举报
看 网站大小 和开发的人多少。
oyqjustice 2009-09-24
- 打赏
- 举报
一个和尚可以提水，两个和尚可以挑水，三个和尚真的就渴得死？
勿犯“拘泥”二字，喝得着水才是正解
勿犯“拘泥”二字，喝得着水才是正解
Dylan_Gong 2009-09-24
- 打赏
- 举报
大家评论的很好。。可能我真是一个做项目太少，或者说做的项目太小,是一个新手吧~~OOAD我是不太懂。。看来我落后了很多。。要加油了。。
yixianggao 2009-09-24
- 打赏
- 举报
呵呵，俺也干了四五年了，一直在努力理解、应用三层开发 Web 应用程序，
不过，俺似乎已经没有那么多疑惑了！
先来解释下“易于维护”四个字，
易于维护并不意味着，需求变了，程序啥都不改就能用，
因为需求是系统设计滴基础，需求变一切皆变，这是必然滴、也是合理滴！
易于维护是指各层分工明确，代码易于理解，
更重要滴是业务层滴对象更贴近现实，这取决于设计，也是系统核心价值所在！！！
好的设计，使对象之间滴关系非常合理，代码读起来很顺畅，反之如同嚼蜡！
这些是俺现阶段对“易于维护”滴理解！
三层开发滴核心是业务层，至于数据层可以通过一些方法使之变得透明，
换言之，当心中不再关注SQL如何处理时，你才真正迈进三层开发滴门槛儿！
总之，三层滴核心是业务层，而业务层滴核心是 OOAD，
不懂 OOAD 设计不出业务层（只有僵尸实体层），没有业务层也就不是真正意义上滴三层！
不过，俺似乎已经没有那么多疑惑了！
先来解释下“易于维护”四个字，
易于维护并不意味着，需求变了，程序啥都不改就能用，
因为需求是系统设计滴基础，需求变一切皆变，这是必然滴、也是合理滴！
易于维护是指各层分工明确，代码易于理解，
更重要滴是业务层滴对象更贴近现实，这取决于设计，也是系统核心价值所在！！！
好的设计，使对象之间滴关系非常合理，代码读起来很顺畅，反之如同嚼蜡！
这些是俺现阶段对“易于维护”滴理解！
三层开发滴核心是业务层，至于数据层可以通过一些方法使之变得透明，
换言之，当心中不再关注SQL如何处理时，你才真正迈进三层开发滴门槛儿！
总之，三层滴核心是业务层，而业务层滴核心是 OOAD，
不懂 OOAD 设计不出业务层（只有僵尸实体层），没有业务层也就不是真正意义上滴三层！
Carpathia 2009-09-24
- 打赏
- 举报
三层的好处在小型项目中的确体现不出来，但在大中型项目中，三层的优势就很明显了。
首先你说的便于修改，我们都知道开发项目不一定由一个人从头到尾的开发，所以这里的便于修改的含义，并不是注重减少代码的修改量，更重要的是让人能更快命中修改的要点，减少寻找的时间。想想如果你刚接手一个半完整的项目要继续开发下去，你会发觉三层可以很清晰得帮你理清里面的思路。
其次,臃肿的问题，这个是不可避免的，分层必定会造成一定量的代码增加
再者，抽象，接口类。对于这一点，我觉得它的优势非常明显，首先，接口的存在使得项目的层次很分明，哪几个方法允许对外，哪几个方法可以被不同的项目多次引用，这个在多接口继承上特别明显，你可以很清楚的明白这几个方法的作用和调用,抽象的优势也基本如此
最后一点，大量的服务器控件我不明白，对于三层来说，UI层是一个独立的表现层次，并不一定需要server controls来运行。
总结一下，如果你还没有发现三层的好处，那就能看出你做的项目太少，或者说你做的项目太小，但是当你进入大中型项目，或者接手一个没有开发完毕的半成品项目，三层绝对可以让你省去不少读代码的时间，这是一个规范，也许对于某些新人来说是增加了代码量，但当你们熟练的时候，你会发现三层其实帮助你们省去了不少开发时间
首先你说的便于修改，我们都知道开发项目不一定由一个人从头到尾的开发，所以这里的便于修改的含义，并不是注重减少代码的修改量，更重要的是让人能更快命中修改的要点，减少寻找的时间。想想如果你刚接手一个半完整的项目要继续开发下去，你会发觉三层可以很清晰得帮你理清里面的思路。
其次,臃肿的问题，这个是不可避免的，分层必定会造成一定量的代码增加
再者，抽象，接口类。对于这一点，我觉得它的优势非常明显，首先，接口的存在使得项目的层次很分明，哪几个方法允许对外，哪几个方法可以被不同的项目多次引用，这个在多接口继承上特别明显，你可以很清楚的明白这几个方法的作用和调用,抽象的优势也基本如此
最后一点，大量的服务器控件我不明白，对于三层来说，UI层是一个独立的表现层次，并不一定需要server controls来运行。
总结一下，如果你还没有发现三层的好处，那就能看出你做的项目太少，或者说你做的项目太小，但是当你进入大中型项目，或者接手一个没有开发完毕的半成品项目，三层绝对可以让你省去不少读代码的时间，这是一个规范，也许对于某些新人来说是增加了代码量，但当你们熟练的时候，你会发现三层其实帮助你们省去了不少开发时间
ncjcz 2009-09-24
- 打赏
- 举报
看实际需要
所有的技术都是为需求服务的。
所有的劳动都是为收获付出的。
每一项新技术出来，都有其优越性。但不可否认的是，在其背后
推动的厂商的目的根本不在此，他们只是为了收获利益而已。
只有最合适的技术，没有最优秀的技术。
所有的技术都是为需求服务的。
所有的劳动都是为收获付出的。
每一项新技术出来，都有其优越性。但不可否认的是，在其背后
推动的厂商的目的根本不在此，他们只是为了收获利益而已。
只有最合适的技术，没有最优秀的技术。
Dylan_Gong 2009-09-24
- 打赏
- 举报
郁闷啦。。。改得我好培辛苦
hbutwzc 2009-09-24
- 打赏
- 举报
简单的系统可以不需要三层
jiezi316 2009-09-24
- 打赏
- 举报
你都改数据库字段了，肯定改得多。这个莫法。
边城的刀声 2009-09-24
- 打赏
- 举报
所谓分层就是为了分享复杂性，为了使程序员在同一时间只关心特定层面上的事
比如在从页面控件上取值时，只是对属性赋值就可以了，然后调用对象的持久化方法（如Save)，而这是持久化方法已经在另一层实现了，所以这是并不用关心。
而比如要用到逻辑层的时候，比如购物车，在写购物车的逻辑时，并不用关心如何存储和值来源于哪的问题，只关心业务。这样也使的程序员轻松不少。
另外楼主说三层要结合大量的服务器控件，其实三层和用什么控件没有任何关系，你可以不用服务器控件。
如果不用三层的话，你修改个字段，恐怕动的地方会更多，不信楼主可以试试
比如在从页面控件上取值时，只是对属性赋值就可以了，然后调用对象的持久化方法（如Save)，而这是持久化方法已经在另一层实现了，所以这是并不用关心。
而比如要用到逻辑层的时候，比如购物车，在写购物车的逻辑时，并不用关心如何存储和值来源于哪的问题，只关心业务。这样也使的程序员轻松不少。
另外楼主说三层要结合大量的服务器控件，其实三层和用什么控件没有任何关系，你可以不用服务器控件。
如果不用三层的话，你修改个字段，恐怕动的地方会更多，不信楼主可以试试
lch163298 2009-09-24
- 打赏
- 举报
我不知道
wx23990915 2009-09-24
- 打赏
- 举报
JAVA里有这么一说：
MVC的优点
◆低耦合性。视图层和业务层分离，这样就允许更改视图层代码而不用重新编译模型和控制器代码，同样，一个应用的业务流程或者业务规则的改变只需要改动MVC的模型层即可。因为模型与控制器和视图相分离，所以很容易改变应用程序的数据层和业务规则。
◆高重用性和可适用性。随着技术的不断进步，现在需要用越来越多的方式来访问应用程序。MVC模式允许你使用各种不同样式的视图来访问同一个服务器端的代码。它包括任何WEB（HTTP）浏览器或者无线浏览器（wap），比如，用户可以通过电脑也可通过手机来订购某样产品，虽然订购的方式不一样，但处理订购产品的方式是一样的。由于模型返回的数据没有进行格式化，所以同样的构件能被不同的界面使用。例如，很多数据可能用HTML来表示，但是也有可能用WAP来表示，而这些表示所需要的仅令是改变视图层的实现方式，而控制层和模型层无需做任何改变。
◆较低的生命周期成本。MVC使降低开发和维护用户接口的技术含量成为可能。
◆快速的部署。使用MVC模式使开发时间得到相当大的缩减，它使程序员（Java开发人员）集中精力于业务逻辑，界面程序员（HTML和JSP开发人员）集中精力于表现形式上。
◆可维护性。分熟视图层和业务逻辑层也使得WEB应用更易于维护和修改。
◆有利于软件工程化管理。由于不同的层各司其职，每一层不同的应用具有某些相同的特征，有利于通过工程化、工具化管理程序代码。
本人觉也得有点吹
MVC的优点
◆低耦合性。视图层和业务层分离，这样就允许更改视图层代码而不用重新编译模型和控制器代码，同样，一个应用的业务流程或者业务规则的改变只需要改动MVC的模型层即可。因为模型与控制器和视图相分离，所以很容易改变应用程序的数据层和业务规则。
◆高重用性和可适用性。随着技术的不断进步，现在需要用越来越多的方式来访问应用程序。MVC模式允许你使用各种不同样式的视图来访问同一个服务器端的代码。它包括任何WEB（HTTP）浏览器或者无线浏览器（wap），比如，用户可以通过电脑也可通过手机来订购某样产品，虽然订购的方式不一样，但处理订购产品的方式是一样的。由于模型返回的数据没有进行格式化，所以同样的构件能被不同的界面使用。例如，很多数据可能用HTML来表示，但是也有可能用WAP来表示，而这些表示所需要的仅令是改变视图层的实现方式，而控制层和模型层无需做任何改变。
◆较低的生命周期成本。MVC使降低开发和维护用户接口的技术含量成为可能。
◆快速的部署。使用MVC模式使开发时间得到相当大的缩减，它使程序员（Java开发人员）集中精力于业务逻辑，界面程序员（HTML和JSP开发人员）集中精力于表现形式上。
◆可维护性。分熟视图层和业务逻辑层也使得WEB应用更易于维护和修改。
◆有利于软件工程化管理。由于不同的层各司其职，每一层不同的应用具有某些相同的特征，有利于通过工程化、工具化管理程序代码。
本人觉也得有点吹
ivws_19 2009-09-24
- 打赏
- 举报
如果只是简单的网站，那似乎没必要
