ASP.NET分层的意义？

[liu204cn]

原先作了一个公司的管理系统（ASP.NET），没有用什么框架，自己写数据访问操作及业务类，也没有什么层，只不过没有把SQL直接写在BUTTON事件下吧了！项目都用了一段时间了，需求还没有完（自己公司的，有的需求就是老板的一个管理闪念）。所以不停的要改，数据库表结构是肯定的。

维护是个问题？

问题一：要不要重构系统。
从开发时间上讲，重做和修改哪个？（困惑是需求永远不会结束，因为老板的管理想法一只会有）

问题一： 用3层结构能不能降低维护成本？

降低维护成本
目前我知道的，操作数据层的方法：ADO.NET 封装、 不能
强类型dataset 不能
ORM(NHibernate) 能 （没用过，我现在赶时间学习曲线？）
SQL Maps（iBatis.net)能 （同上）
代码生成器 （自己写吗？（时间呀），动软用过复杂查询还是自己写，表结构一变玩完（可能和个人水平也有关系））

综上：那么为什么要分层，看一下分层的好处？

Martin Fowler在《Patterns of Enterprise Application Architecture》一书中的答案：

1、开发人员可以只关注整个结构中的其中某一层； （晕死，**公司不是按层分任务，是按功能模块，一个功能功能模块一个人搞定）
2、可以很容易的用新的实现来替换原有层次的实现； （增加业务规则肯定增加表，好了3个层全加了）
3、可以降低层与层之间的依赖； （我就一个层还降低什么，）
4、有利于标准化； （这个需要长时间磨合）
5、利于各层逻辑的复用。 （我们的业务太具体话，能复用的公用的东西我肯定先找下网上有没有现成的代码 哈哈）



另一种答案：（本人比较认同）


把表现层分出来，是为了 移植 C/S,B/S 。(你可以引申)
哈哈，现在你不怕老板要把你的网站做成桌面程序了。

问题又来了，老板说我们的系统换成 Oracle ，晕了又要重写代码了。
呵呵，如果这时你的数据层十分出来的就不是问题了。

总结：2层 表现层+ 综合层（业务、数据） （就可以 方便移植 C/S,B/S ）；2层 数据层+ 综合层（业务、表现） （就可以 方便移植不同数据库）；
3层就是都OK了。

我们的系统只用SQL Server 数据库，也只是用B/S结构。 分层的意义何在？

[fuda_1985]

一般如果有那个需要还是分一下吧，要不到后来扩展是个问题的！乱乱的感觉。

[NqIceCoffee]

关注一下

[suyiming]

ddd

[paulin]

除了楼主说得优势外
我觉得分层的还一个好处是可以有助于小组分工合作。
比如ui层由擅长的人去做，数据层单独有数据库更擅长的人做，
业务逻辑层另一部分人去做，这样的话，只要几部分人提供彼此接口就可以顺利开工了
而不需要每个人都这几方面的工作掺杂进来。

[guyan033]

应该是日后好维护是最得要的

[zhensoft163]

三层的理解：
1、UI层：我说的这个UI层可能包含了很多的概念，除了大家都知道的window form和web form，它还包含了那些可能没有用户界面的用户接口，像window service，web service以及.Net remoting service等的入口，它们都可以看作UI层，而UI层应该只和业务逻辑层发生关系。有些系统尽管划分了层次，但却将部分的业务逻辑放在UI层，这就增加了UI层和业务逻辑层的耦合度，不利于UI层的增加或变换，因为如果需要再增加另外的一个UI层，而新增加的层中又包含了原有UI层的部分功能，这时新的UI层不得不再一次实现同样的功能，如果已实现的功能不符合要求，需要修改时，又不得不在已实现了的多个UI层中进行改动，这样不但增加了工作量，而且增加了出错的可能性。
2、业务逻辑层：所有的业务逻辑处理的集中地，它为UI层提供服务。比如一个购物系统，当客户下了订单时，一般应该做这些事情：1、检查提交的数据的合法性；2、验证客户信息；3、检查商品信息，比如商品是否存在，是否有足够的库存等；4、提交订单。这四步对于UI层来讲是透明的，就是说UI层只调用业务逻辑层的一个相应的方法，而不是亲自完成这四步功能，因为这四个步骤实现了一个完整的业务逻辑，它们不可以分开。如果需要公开一个Web Service，供客户提交订单，Web Service的实现也只是简单的调用业务逻辑层的一个相应的方法。
3、数据（库）层：这一层才真正的实现了数据的存取，它为业务逻辑层提供服务。在这一层上不需要关注业务逻辑，只是存取数据。对于确定只用一种数据存储方式来讲，这些就足够了。但在一个分布式的系统中，这种简单的实现是不够的，因供存取数据的不一定来自数据库，也可能来自其他数据文件，比如XML、Excel等，不同的数据库之间也有很大的差异，这些异构的数据对业务逻辑层来讲都是透明的，业务逻辑层没必要了解数据存取的细节。那么如何才能实现这种结构？通常的办法是为数据（库）层提供一个接口，业务逻辑层只是调用接口所约定的方法，这样通过接口就可以实现很多异构数据的存取了。

三层的好处很多：
比如具有灵活性，可以随意调整组件的位置和服务器的位置，可以增加和修改各个组件，更主要的是具有了商业逻辑的灵活性，因为中间层的商业逻辑层负责商业逻辑。
比如说容易更新，不用重新编译整个工程就可以更新功能，替换一个组件不会扩大影响到整个工程。
比如说容易维护，各层意义明确，不会出现商业逻辑和各种访问控制混合在一起的情况，而且分层的好处是，各层可以使用不同的配置，各个服务器的维护也变得简单。
比如说有天生的网络化，只要配置好一个外部环境，各个组件运行时不会注意到自己访问的是网络资源还是本地资源，这种分布式的好处对于一个企业来说是急需的。

[liu204cn]

有多少？公司不是按层分任务，是按功能模块，一个功能功能模块一个人搞定

[twin21cn]

大型的或这更改比较频繁的分层比较好，小的就无所谓了（个人观点，我是菜鸟）

[游北亮]

分层，无非就是松耦合，便于维护，也便于理解
没错，你们一个人做一个模块，但是如果再给你一个模块，那么连接数据库的那些代码你是不是又要重写一遍？
或者说，你要再拷贝过来一份，如果出了Bug，你是不是10个模块都要去修改？

对数据库的访问可以单独做成一个项目，然后引用到你做的所有模块中去
这个是我认为的分出数据层的意义


表现层和业务层分开，举个例子：工资计算，今天老板说：工资都是底薪加奖金，
好，做了个程序，10个页面都用这个公式计算，并显示工资

明天老板说，工资制度改革，改成底薪+奖金*表现的百分比
这时你所有牵涉到计算业务的地方都要改了
如果所有页面都只用于显示工资，计算放到业务层做，这样就只要改业务层关于计算的地方就好了

[HarrisonCao]

分层只有在需求很明确的情况下好用，否则一修改表，三层代码全要修改。如果考虑到支持多数据库的话可以参考下Microsoft的petshop4.0里的工厂模式

[hzfujiomo]

好

[Rail100]

lz以前经历过公用厨厕吗，挤过宿舍没有？为什么结婚了想搬开住？想清楚这些后就明白为什么要分层了。

[cheng_feng001]

分层，一个永远讨论不完的话题

[jasonboy]

大项目分层绝对有必要，代码清晰，便于后期维护
小项目就算了，还不够折腾

[Magicwords]

要从根本上解决的话要用业务流引挚，

[stonec]

要顶，虽然是老话题了

[lihongdian]

分层的概念已经过时了.现在都是OO了

[Jack123]

分层

[greatverve]

看情况了，系统太复杂，太庞大，不分层怎么办。