三层架构的设计思路,主动思考有重赏

[「已注销」]

学了三层架构,做项目用了不少次,在设计上总感觉不爽,

如果数层访问层不涉及一点业务逻辑,则好多方法都差不多是费物,很占资源,

而如果在业数据访问层绕着业务逻辑设计,性能提高了,可"高内聚"这一原则又说不过去了

很是郁闷,

各位发表一下对三层架构的使用心得,以及看法等

有资料发到
[e-mail]

重谢

[lsfv00011]

概念需要计较。
如果你项目小．那和概念计较不计较没关系。而是你要调整你的概念。很小项目，只需要２层．那么这也是一个概念。

[「已注销」]

谢谢各位啊

[CloneCenter]

数据访问层本来就是只是负责和数据库之间的处理，如果从严格意义上来说，是不应该有业务逻辑的处理的。划分出数据访问层，只是为了将数据库种类的不同，使用不同的数据访问层而已，某种意义来说，是为了应付不同的数据库系统的。
分层多了，速度就会下降，效率就不会多高。如果系统追求速度，很多需要和数据打交道的东西，可以放到数据库中去处理，例如各业务数据之间的关系，数据有效性判断，都可以这样实现。

[lsfv00011]

数据访问层划分就是接口思想。
应付不同数据库是一种可能。
还有比如从sql语句．转到存储语句．原来的sql方案不变．加一个存储的方案．如果有接口的话．只要更改配置使用新的方案．
有接口的话，也可以很好应对分布开发的需求。

[yanlongwuhui]

[Quote=引用 27 楼 lsfv00011 的回复:]
概念需要计较。
如果你项目小．那和概念计较不计较没关系。而是你要调整你的概念。很小项目，只需要２层．那么这也是一个概念。
[/Quote]
只要明确分层的目的，该2层就两层，该3层就3层，很多时候还需要分多层

[scy251147]

mark

[xxxswl]

[Quote=引用 35 楼 lsfv00011 的回复:]
引用 31 楼 xxxswl 的回复:
我是个菜鸟：对三层架构 感觉很肤浅
三层架构 就是因为 项目的规模比较大 代码很多  一个类放不下 3-5个类也放不下
就把功能类似或着在同一开发阶段的类放到一起 于是“层”就出现了
本菜鸟眼里 层的优点就一个：方便管理 和 维护

我也没学多久．但感觉此观点不妥．
不是放不下．代码多的原因．
只是给刚刚学的讲下．别让不妥观点，让自己走弯路．自己就走了很多弯路。
会了基本语法后．确实…
[/Quote]
谢谢拉 我这就去 补充一下设计模式的知识

[jlj84237485]

帮顶一下

[「已注销」]

顶一下

[mjjzg]

去瞧一下MVC的利与弊
简单的说,三层架构的优点:
1.在开发项目的时候开发人员只需要注重整个架构中的某一层
2.可以很简单的用新的实现替换掉旧的实现
3.可以降低层与层之间的依赖
4.有利于标准化
5.利于各层逻辑的复用
即:分散关注,松散耦合,逻辑复用,标准定义
而至于缺点
1.降低了系统的性能
2.有时候会导致级连的修改
以上纯属个人经验说述,楼主也可以上网找一下它的利与弊
俗话说"金无足赤,人无完人",所以分层史的结构也不可避免的会有一些缺陷了.......

[「已注销」]

顶起来

[koukoujiayi]

谈谈我用三层:
1.vs2005中强类型的DataSet就是微软真对三层中的DAL层的,
强类型的DataSet集中所有sql语句,且所见即所得,
功能非常干净,(没有任何一点业务逻辑),即该层就是访问数据库的!!
2.页面提倡用ObjectDataSource,这个ObjectDataSource既可以直接连DAL层,
也可以连用户的中间层,也就用户的业务逻辑,非常灵活!!
3.不用ObjectDataSource,也可用传统的方法实例化强类型的DataSet中的类!

我觉的比传统的三层要好许多,编层的代码量几乎减少一半!当然也有一些限制,
这些限制三言两语很难讲清楚,这里从略了,
楼主不妨试试!!

[xxxswl]

真的是有点对不住楼主 本菜鸟上面的回答是错的 仅仅贴点边
希望现在说的东西是对的 哈哈
我认为 ：3层架构 是基于面向对象的 那么必须掌握面向对象这一伟大的想法 才能得心应手
如果能做到2点 相信 “3层架构”的神秘面纱会自然解开
1。熟练使用一种OOP语音
2。真正了解 设计模式 要表达的思想

[NOYISUPER]

分层的作用说白话就是把要做的事分成几步
比如炒个菜要买菜--洗菜--切菜--炒菜

假如买菜就是DAL层
那么我把洗菜切菜炒菜啥的工作形成模式后
不管我买的是大白菜还是小黄瓜，洗菜，切菜--炒菜这几个步骤都不需要重新更改

同理，我换个方法洗菜啥的意思也一样

分层就是把工作程序细分，同类型的相近的工作分在一起，那么我哪部分工作要改动，就只改那个步骤就是了，不需要改动其他步骤

。。。。。。。。。。。。感觉越说越白菜，不说了……一家之言……

[emenwin]

对于小项目来说 三层的性能并不好。数据访问层包括业务逻辑层都会有楼主所说的‘浪费’的内容

三层主要是方便大项目开发程序员之间的协作 方便后期的修改

[NOYISUPER]

怎么不能修改帖子，我郁闷

突然觉得上面说的偏题里

高内聚是指这个功能模块的高度聚集，就是例如洗菜这个步骤的所有细节全部聚集在洗菜这个组件里，这就是高内聚
而洗菜这个组件什么菜都能洗那就是低耦合

但要什么菜都能洗的前提就是洗菜这个组件的代码量肯定会大，毕竟要有很多的逻辑判断，例如菜品分类等，自然就会影响到性能

所以，还是要提倡我们中国伟大的——————当当当当

中庸…………

平衡就好，平衡就好

[lsfv00011]

但要什么菜都能洗的前提就是洗菜这个组件的代码量肯定会大，毕竟要有很多的逻辑判断，例如菜品分类等，自然就会影响到性能

所以又要用到接口来实现工厂．
接口统一洗菜．
至于新加了菜．临时加一个实现了洗菜接口的实现就可以了。

模式越来越多．
需不需要．还是看具体情况．

[伤寒泪]

在数据访问层不可能不带一丁点的业务逻辑，当然这个也要看如何来看。。
比如，将ResultSet里的东西给一个对象，那这个时侯其实还是属于业务逻辑层的范畴，不是纯粹的数据层的范畴
所以，具体问题还得具体分析。

[「已注销」]

现在在看设计模式的教程,很不错,就是有点长,

很有启发

[xubaoduo_77]

很不错.人很多嘛.心德是有的,但是已经没地方说了,呵.