传统: 客户端直接与数据库进行交互3层 ： 不是比 客户端与中间层通信 在由中间层与数据库交换更快吗
除非是客户端和数据库距离很远，而中间层和数据库在一起，可以用通信把数据传输过来，比直接访问数据库快。这样才解释的通。
而确切的3层是都在一起的 ，请人指教谢谢了
而大家通长做的也没通信 而只是把东西分给了3个单元，这种的我感觉更是脱了裤子放屁的事怎么解释下
除非是客户端和数据库距离很远，而中间层和数据库在一起，可以用通信把数据传输过来，比直接访问数据库快。这样才解释的通。
而确切的3层是都在一起的 ，请人指教谢谢了
而大家通长做的也没通信 而只是把东西分给了3个单元，这种的我感觉更是脱了裤子放屁的事怎么解释下
我要明白就不问了 别在这放屁好不
你完全没搞懂这个概念.
明白还问什么。
to zhudaifu
一个人需要是数据库层的接口只有他自己知道 别人怎么会知道呢？
怎么才能做到分工呢？不明白。
我自己认为这么写的好处就一个，就是万一那天需要远程数据库访问的时候可以改成通讯获取数据的方法。这样只需要该数据访问层了。而大多数据的都没这个必要的
至于维护 写好注释都一样的，写在一层或写在2层没什么分别。我是请大家帮助来了，不是听有些人那吓骂人的，请自重
我不太了解。NET现在想学习下。
在VS2005中你建立个东西 不是有index.aspx（页面）和index.cs（逻辑）吗？
不是已经分开了吗 不知道我理解的这2层对不对。
3层 ： 不是比 客户端与中间层通信 在由中间层与数据库交换更快吗
除非是客户端和数据库距离很远，而中间层和数据库在一起，可以用通信把数据传输过来 ，比直接访问数据库快。这样才解释的通。
=================
你这是什么鸟道理,谁跟你说的? 要是在一台机器上的话 一个做了2件事 一个做了一件事 谁快 不是很明显吗？
这东西不是一两句话能说清楚的.只能是在实际的应用中才能体会到他的好处.才能体会我们为什么用他为什么一些公司全要搞些分层结构?其实我在3楼都说了他的好处你要明白,三层结构不是为了系统运行速度快而采用,恰恰相反.他的性能会慢些.开发难度也相比较大但为什么我们要用呢?
对于一个系统来说.我们不光要考虑他能开发出来,能正常交付就ok了,而我们要考虑到他的后期的维护,扩展等等很多东西
而对项目的分层可以很好的降低藕合,使后期的扩展维护起来非常方便,又利于团队开发与分工合作比如一个UI层的开发人员他只管去调用业务层的方法就可以了.他不用去管你的业务层是怎么具体实现的
aspx与aspx.cs可以理解为是一种界面展现与页面逻辑的分离.相比以前asp的混编模式,他是一种进步
当然在asp.net中也支持html与c#代码混编的方式
假设我们的程序设计中外存的读写是针对文本文件的操作，但是需求改变了，需要对数据库进行读写，那我们只需要对DA层进行重写就行了，不用全代码去寻找每个读写文本的地方进行操作。这才是分层设计的概念吧。
调用不同的类中的函数需要时间和空间成本，但是降低开发和维护成本。
逻辑层次 只是逻辑上的划分, 比如定义了一些DLL,分别负责不同层面的逻辑处理, 但都部署在同一台服务器上, 这些DLL在同一个进程空运行, 那么逻辑上是三层的 或更多层, 但只是一个物理层. 逻辑层次间有数据传递,但在同一个进程空间内运行,只是调用层次的消耗,没有进程间通信,更没有跨域(机器)调用和数据传递物理层次 是部署上的划分, 逻辑层上的组件 分别部署在不同的服务器上, 或同一服务器上用不同的进程实现.不同物理层次间需要跨进程通信,甚至跨域(机器/网络)通信,除了调用层次的消耗,还括了跨进程处理的消耗,跨物理连边界抽消耗(序列化/反序列化,网络协议打包/解包,网络通信等)
讨论的时候很容易混了.其实 逻辑层次的话 , 细分起来 可能还不止三层, 我通常定义 :部署在物理分布的 界面层的 逻辑层次有:[/b] 界面(显示)层, 界面控制层(即界面的后台代码,这是与业务层联系的通道), 远程代理层(如果物理三层分布的话,界面控制层需要通过该层与远程服务器交互,如果不是物理三层,则没有该逻辑层)部署在物理分布的 业务层的 逻辑层次有: 远程服务层(物理分布时才会有,用于向远程公布业务对象), 业务对象层(这一层是真正的业务逻辑处理层), 数据访问连接层(负责业务对象与数据访问的通道, 有时候把这一层定义为逻辑上的数据访问层)部署在物理分布的 数据层的 逻辑层次: 数据访问层(有时把这一层划到业务层去了,这里就没有了), 关系数据库系统及其中的数据存储和SP/FUNCTION等
其实有时候说话就是 说者无心 听者有意 对把 我真心的道歉还有我是没见过大系统。做CS的刚学.net好好学习 努力进个大公司看看去:)
分出ui层可以今天是winform的ui明天换成webform的ui
分出业务逻辑层可以我改我的逻辑，你改你的界面，要改逻辑了，不用在界面逻辑数据操作混杂的文件里幸苦
分出数据层可以新增删除什么的基本操作写一次就够了，你们做业务逻辑层的都来调我的吧
你可以多在网上找下微软的架构和别人写的架构,MVC,PetShop,EnterPrise Library,网上很多OOP思想不错的多层架构,还有一些ORM框架. 时间充裕的话,看看设计模式,在平时做系统的时候,试着把一些设计模式的思想套在项目里面敲一下。进步会很大的。
花那么大的代价去写几个项目,还要相互间的引用,那是你还不
理解为什么要用3层,3层分为:表示层(UI),业务逻辑层(BLL),
和数据访问层(DAL)主要是要把各自之间的分离开,是程序更
加的面向对象也是为了以后项目可以不用修改代码就可以添加
一些功能做准备,加大代码的重用.
Database类
a.ExecuteSql(string)执行一条Sql命令返回受影响的行数。
b.GetDataRow（string)执行一条Sql，返回第一行的数据（DataRow对象）
c.GetDataSet（string）执行一条Sql，返回一个表（DataSet对象)
d.Open（）打开数据库
e.close（）关闭数据库
f.Dispose（）释放连接资源
g.Connection，SqlConnection对象
h.ConnectionString，数据库连接字符串 这些都是大家都用的到的肯定要单独写出来的 便于大家一起用。
在比如整个系统有很多地方都要建立树 当然要写个公共的函数了
但我的意思是 比如登陆的界面由我写 需要一个只有我用的到的函数 难道我还非要写自己的DB中吗？
去自己感觉是很累。而且这个DB层的函数肯定是由我写的 别人写不了 。 分工写更不可能 了？
我的想法那有错误在指点下 谢谢。真心的谢谢
１、表现层（UI）：通俗讲就是展现给用户的界面，即用户在使用一个系统的时候他的所见所得。
２、业务逻辑层（BLL）：针对具体问题的操作，也可以说是对数据层的操作，对数据业务逻辑处理。
３、数据访问层（DAL）：该层所做事务直接操作数据库，针对数据的增、删、改、查。三层架构的优点:
1、开发人员可以只关注整个结构中的其中某一层；
2、可以很容易的用新的实现来替换原有层次的实现；
3、可以降低层与层之间的依赖；
4、有利于标准化；
5、利于各层逻辑的复用。三层架构的缺点：
1、降低了系统的性能。这是不言而喻的。如果不采用分层式结构，很多业务可以直接造访数据库，以此获取相应的数据，如今却必须通过中间层来完成。
2、有时会导致级联的修改。这种修改尤其体现在自上而下的方向。如果在表示层中需要增加一个功能，为保证其设计符合分层式结构，可能需要在相应的业务逻辑层和数据访问层中都增加相应的代码。