一层还是三层？什么时候三层，什么时候不三层？

Question

　　做网站最基本的一个功能就是做一个栏目导航，如果这个导航想做成动态的（即需要从数据库里提取数据）那么要如何实现呢？ 

简单的方法——DataTable

Answer 1

LZ 3fen a ~~~~~~~~~~~~~

Answer 2

http://topic.csdn.net/u/20070315/10/4082706a-3b35-4abb-bbce-c9972953193c.html时间真是快啊 ~  一晃三年过去了我在上面帖子回复时 还只是菜鸟  , 只了解一点面向对象的皮毛但到是非常愿意与人谈论 OO ，以为自己懂的不少，实则贻笑大方。反观现在 ， 对面向对象的理解较之前深入不少， 但却很少与人谈论OO 了原因很简单， 思维方式不一样， 你不能把自己的思维方式强加灌输在别人身上 ，只能说是仅供参考。 分层也是如此，没有万能的， 合适的才是正确的， 但要保证程序的稳定性和维护性。何必一定要执着于三层 或 N 层呢， 如果你真的需要分层的时候 ，自然就会想清楚如何处理了。 

Answer 3

刚才未看你的贴子先看了评论所以就直接写“”了，看完你的帖子还是有话要说的：
我刚工作的时候接手了一个OA，整个OA的写法就是楼主所说的两层写法，后台写SQL语句，调用已经写好的一个数据库访问类也就是楼主所说的数据库访问函数库，这样需求一变更，程序员只需要调整后台的SQL语句就搞定，后来项目升级，打着为了方便项目管理的口号，把原先的‘两层’弄成‘三层’，这一过程吃进了苦头，需求一变，程序员除了改界面和后台代码还要改数据层。
使用三层的优点：
1.作为项目管理来说，这样做十分规范，一个团队都是用这样的方式编程，以至于新人也能很快进入状态。否则代码会各有各的风格，我见过这样命名的 Dim i,ii,iii as integer
2.项目越来越多模块的时候，三层给你带来的好处就像潘多拉星球一样，到处都是接口，你想获取人员信息，就调用new BLL.Base_Employee().GetList(),想获取部门信息就调用new BLL.Base_Department().GetList(),这就是复用性，楼主你可以想象一下你想要什么数据就立马能获取什么数据的快感了。
3.当有一天，客户和你说：“大哥，我们老板决定将你们的软件由B/S换成C/S”，我不知道你考虑过没？以上是我对三层的愚见，欢迎指正。BLL层绝对不仅仅只是个传话筒，利用这一层你可以把缓存发挥得淋漓尽致，觉得麻烦就不写这层了。至于用什么模式：其实客户并不关心过程，你的团队用什么方式顺手那就用吧，最后能舒服的做出项目来就行了。其实现在关于三层的代码生成器已经一大堆了，楼主你也可以针对你的团队写一个代码生成器，消减重复的工作量

Answer 4

看了lovecherry的回复，我觉得很有收获

Answer 5

@kinglot
回21楼不知道当初，你们把两层改成三层，原因是什么？没有看明白。是因为两层不能够满足客户的需求？还是不便于维护？还是仅仅想体验一下三层？我并不否认真正的三层的好处。只是我觉得我的这种写法，肯定不是真正的三层，对吧？new BLL.Base_Department().GetList(),不知道这么做有什么快感，希望能够详细说一下，呵呵。

Answer 6

两层已经满足客户的需求，必须承认的是用两层来开发，程序员必然要清楚数据库结构，这样会出现一个问题：需求一变，程序员不经过项目经理任意的改变数据库结构。这样当项目越来越大（主要是指模块越来越多）的时候，原有的需求文档以及数据字典都形同虚设，这个程序员一旦辞职，新来的开发人员接手十分吃力，甚至导致项目失败。后来决定用三层，主要目的是分工，不让程序员弄数据库而是根据文档定义的接口来编程，而数据库设计及接口定义由专人设计。事实证明这样做，的确是减少了项目风险。（以上是当时我们采用三层的最主要目的）至于“new BLL.Base_Department().GetList(),不知道这么做有什么快感，希望能够详细说一下”。
主要就是复用性，就是说程序员根据团队的接口文档，调用这个方法就能返回部门信息，而不需要他再去写一遍SQL，你不可能为所有这些个数据都做一个用户自定义控件的。

Answer 7

如果项目大的话，分层多层，就是可以并行开发对修改，扩展也比较容易业务逻辑不复杂，没必要弄个三层，或者用Linq to SQL 分层也是缺点的，那就是会增大响应时间

Answer 8

分层是程序架构明确,   
分层只是一种工程方法，可以用新的实现来替换原有层次的实现；  
有利于标准化；  
利于各层次之间的逻辑复用。
http://topic.csdn.net/u/20090524/13/2f13a60c-9ae8-4f1c-84ea-65b74b01ee99.html

Answer 9

其实分层已经严重误导了刚学的童鞋们。
他们有的人只知道分层，一个企业网站，几条sql就搞定的页面，还要分层。
都是受了分层的误导，只是为了分层而分层。
而不是为了需求而分层。

Answer 10

protected void Page_Load(object sender, EventArgs e)
{
  DataAccessLibrary dal = DALFactory.CreateDAL();
  dtChannel = dal.ExecuteFillDataTable("SELECT channelName, URL FROM CMS_Channel ORDER BY Sort ");
  dal.Dispose();
}其实我觉得上面的dal.ExecuteFillDataTable()方法最好接受像ID、用户名、密码、等这样的参数，而不是SQL语句，真正的SQL语句写在数据访问层，一般我们从UI层获得ID、用户名等（当然本例不需要参数，直接将导航数据表里面的数据取出来就可以），然后将它们作为参数传给BLL层（用两层的话，就是传给DAL层了），然后返回我们想要的结果
数据访问层public DataTable ExecuteFillDataTable(int flag)//flag表示用户类别，根据用户类别产生不同导航
{
    //……
      SqlCommand com=new SqlCommand();     com.Connection=conn;
     com.CommandText="select * from tb_Navigation where ID=@id";
     com.Parameters.Add(new Parameter("@id",flag));
     
    //……Fill DataTable    Return table;  
}
UI层protected void Page_Load(object sender, EventArgs e)
{ 
    //…………
    //获取用户类别flag
    
    DataTable table=dal.ExecuteFillDataTable(flag);
    dal.Dispose();
}

Answer 11

努力干活吧，1000次地重复你的SQL语句，大项目用不着你搞设计、做管理、负责外包、考虑各种客户端平台的战略合并等等，哪些都由更有进取心的去做。

Answer 12

客户端检查不应该作为业务逻辑的组成部分,而只应该作为提高用户体验的手段 
aspx.cs这一层应用作值的抓取、推送和验证。service用作业务逻辑 dao用作数据库操作 底层是数据库连接等。。

Answer 13

分层是有好处的。MVC架构模式，N层表现模式，一直都是这样用的，为什么不用？理由是这个项目小，不用分工，这个项目没有变动，以后也不想重用

Answer 14

OO 三大特性 基本上MVC都用到了

Answer 15

他在臭屁....lz的意思是项目是有适用度的盖泥瓦房的建法与高楼不同的问题,他跑来说“lz你丫就是一个民工连包工头都算不上”....两码事记得某本设计模式的书中特意给看了一段儿 200多行的hello world，异曲同工

Answer 16

通常建议使用三层框架，楼主可以下载一个例子，加深你的理解：
http://blog.csdn.net/bluedoctor/archive/2010/01/24/5251913.aspx