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

Question

学了三层架构,做项目用了不少次,在设计上总感觉不爽,如果数层访问层不涉及一点业务逻辑,则好多方法都差不多是费物,很占资源,而如果在业数据访问层绕着业务逻辑设计,性能提高了,可"高内聚"这一原则又说不过去了很是郁闷,各位发表一下对三层架构的使用心得,以及看法等有资料发到
[email protected]重谢

Answer 1

现在学做小型的ERP  没有用到3层了帮你顶哈

Answer 2

一般理解三层为：数据连接层、数据处理层（逻辑层）、页面表现层也可以再细分一点的数据库、存储过程、数据连接、数据处理、页面逻辑、WEB2.0

Answer 3

http://www.cnblogs.com/gaoweipeng/archive/2009/02/05/1377855.html

Answer 4

“层”是什么？ 模块化，以及调用。1. 数据持久层 --》数据存取模块，专门是负责数据存取的一个模块。  
2. 业务逻辑层 --》数据处理层，主要是处理各种数据和逻辑控制， 如果逻辑简单，不必要有这层，直接调用 数据存储模块进行存取就行。 
3. 表现层  --》 接收逻辑模块处理的数据和把用户输入的数据交给逻辑模块来处理。 而这三个模块的调用关系 ，对于用户刚好形成一个由近而远的情形， 表现模块最近，持久模块最远 ，从而有了层次感，所以在 MIS和WEB这些以数据为核心的软件中，有了3层这个概念。在软件开发中，模块化是非常重要的。站在模块化的角度来考虑和理解层，是比较容易理解的。

Answer 5

http://terrylee.cnblogs.com/archive/2006/06/01/334911.html

Answer 6

如果数层访问层不涉及一点业务逻辑,则好多方法都差不多是费物,很占资源, ：访问层本来就不应该涉及业务逻辑．可以看作原子操作。我觉的正确的理解是。你的迷惑来源于某个操作中你的业务逻辑层本来就简单．这和数据层没有关系。
通俗一点，你简单关我什么事情。有别人复杂需要我结合几个操作好不好。我日。而如果在业数据访问层绕着业务逻辑设计,性能提高了,可"高内聚"这一原则又说不过去了 ：我理解为这个错误的方法．不是非要严格按照３层的规范的问题．而是逻辑上的问题．
通俗一点：你做主板就做主板好不好。还把cup给我固定上去了。以后我怎么升级．我日。楼上一个说了：我感觉三层架构主要是面向接口的操作思想 
同意．虽然没有interface．其实就是接口的思想．

Answer 7

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

Answer 8

有４人帮的２３种设计模式的书．
视频教程有微软的webcast中有视频教程．
刚学的时候自己走的弯路太多了。
所以给刚学的朋友发个自己觉的好的教程。
http://www.microsoft.com/china/msdn/events/webcasts/shared/webcast/Series/CsharpOOD.aspx
（设计模式的。）
别对基本概念理解错．要不绝对会影响学习速度．这是我以前对３层提问回复的。可能也不太正确。写一个演变过程给你。 得到用户信息表格 
一．一层．conn．cmd　(this.label=....)，显示． 
二．发现如果要商品表，又要重复　conn，cmd，得到数据。所以 
　　把重复的集中起来．分二层． 
　　第一层：class　dal 
      ｛ 
          string conn; 
        dateset get() 
          { 
            cmd....... 
          } 
　　　｝ 
　　第二层：this.label=get(得到用户); 
　　　　　　this.label=get(得到商品); 
三，后来方法越来越多 ,得到用户基本信息，得到用户名字，得到用户．．．get１(),get2,get3,get4()..... 
  　发现方法里面都用了一些基本的数据操作．cmd.ExecuteNonQuery()等。．．．． 
　　　又把他们集合起来． 　　　class　dal 
      ｛ 
          string conn; 
        dateset get() 
          { 
            cmd....... 
          } 
　　　｝ 　　　变成 
　　　　class　dal 
      ｛ 
          dateset get１() 
          { 
            dbhelper.get１(); 
          } 
　　　　　｝ 
        class dbhelper 
        { 
        string conn; 
          } 
    这里还是二层．只是加了一个数据帮助类 dbhelper. 
四，得到用户信息后 .this.label1=rs["name"].  this.label2=rs["id"]..... 
    可以很好操作。 
　　　添加信息方法：name=this.lable1.text; 
                id=this.lable2.text;                   set name=name,id=id.       可是可以．但是我们用集中的思想．如果表的信息都在集中在一起那该多好． 
      class user 
{ 
string name; 
int id; 
} 我们就可以 
user=getone(); 
.this.label1=user.name; this.label2=user.id.tosring();...... 
到现在我们有了user（model），dbhelper（帮助类） dal(数据访问类) 五，程序老变． 
　　得到用户信息．后来老板说，不是所有人都可以得会员信息．除了我。 
　　　ok　．到dal层中加一个修改 get1()只给老板用．     副总又跑过来。老板说我也可以用．又某某某跑过来。．．． 
      刚催 get1();给所有人用． 
      再加一个 check() 
check() 
{ 
... 
get1() 
.... 
} 
到这里来判断．   (重载一样) 
　　要求越来越多．dal．越来越杂． 
　　但是你又发现。里面还是有写没有变．而且变的部分．都用到了那些没有变化的方法． 
　　老思想．把不变的集中起来。变的出去。   class bll 
{ 
    privite static readonly dal=new .....(); 
    check() 
{ 
..... 
dal.get1() 
.... 
} 
    
} 
到现在我们有了user（model），dbhelper（帮助类） dal(数据访问类) bll(逻辑层) 
六，后来又发现getone()，变来变去．今天是sql代码，明天是存储过程． 或者数据库要更换． 
　　抽象出来． 
    interface iget();   sqldal:iget 
  prodal:iget 　　用反射来实现工厂． 
  ....不写了。反正就是这个意思了。如果变化不大．就这样分层就可以了。 
　工厂层．接口层．就不需要了。 

Answer 9

1.分层的优势之一是隔离变化：
举个例子，你在程序中的某个SQL语法有问题，修复这个SQL语法问题后你只需要发布数据层的组件，业务层和表现层的组件不受影响。
2.分层的另一个优势是使代码重用更容易识别：
数据层代码一般是按照数据表为单位进行组织的，在业务层里使用数据访问代码时很容易识别出需要的方法是否已经存在，使代码重用变得简单；业务层的代码在表现层里使用也有这样的优势，只不过是以业务对象为单位进行组织的。

Answer 10

我觉得分不分层，分几层，没有一个固定的约定，还是要看你系统本身的需求而来。
分层架构，在一定程度上是用运行效率来换取系统的灵活性。比如在做数据访问层时，如果直接使用SqlClient来读写数据会更加直接高效，但如果系统有需求说今后有可能会用到Oracle数据库，那么此时你或许会使用工厂模式、依赖注入，甚至是动用框架来达到这一目的。但无论如何，与直接使用SqlClient相比，这样做是会引起效率损耗的，毕竟存在额外的系统开销。
再比如，如果你在做一个网站，而这个网站的主要功能是收集大量数据，并为用户提供这些数据的统计分析结果，那么，将这些分析型的处理过程置于数据库的存储过程似乎更加高效，但如果你需要考虑后台数据库的变更，那么则应该将非关键性的分析业务从存储过程中抽身出来，毕竟存储过程是数据库相关的，引入太多会影响系统的移植性（甚至有些数据库直接不支持存储过程）。
因此个人认为还是需要具体情况具体分析。

Answer 11

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

Answer 12

谈谈我用三层:
1.vs2005中强类型的DataSet就是微软真对三层中的DAL层的,
强类型的DataSet集中所有sql语句,且所见即所得,
功能非常干净,(没有任何一点业务逻辑),即该层就是访问数据库的!!
2.页面提倡用ObjectDataSource,这个ObjectDataSource既可以直接连DAL层,
也可以连用户的中间层,也就用户的业务逻辑,非常灵活!!
3.不用ObjectDataSource,也可用传统的方法实例化强类型的DataSet中的类!我觉的比传统的三层要好许多,编层的代码量几乎减少一半!当然也有一些限制,
这些限制三言两语很难讲清楚,这里从略了,
楼主不妨试试!!

Answer 13

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

Answer 14

分层的作用说白话就是把要做的事分成几步
比如炒个菜要买菜--洗菜--切菜--炒菜假如买菜就是DAL层
那么我把洗菜切菜炒菜啥的工作形成模式后
不管我买的是大白菜还是小黄瓜，洗菜，切菜--炒菜这几个步骤都不需要重新更改同理，我换个方法洗菜啥的意思也一样分层就是把工作程序细分，同类型的相近的工作分在一起，那么我哪部分工作要改动，就只改那个步骤就是了，不需要改动其他步骤感觉越说越白菜，不说了……一家之言……       

Answer 15

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