求批评，求指正，求建议，各种求教！我印象中直白的三层。

总是在看别人的在谈三层，说的很奔放，但是自己看起来，感觉还是有些迷茫，倒不是说什么地方不懂，只是有些具体的做法还有待于学习。
学习了CSDN中的很多文章，但是对于对名词不是很敏感的我来说，还是比较就接，倒不如把我的方法写出来，让各位大哥看看，不多说了，先简单的谈下自己对三层的理解，希望

各位大牛多多批评，多多指正！

因为对三层还不是很了解，所以暂时是使用工具生成的DAL，MODEL
DAL程序集的内容主要是根据数据库生成的对各个表的增删改操作的方法体。
Model的主要内容是根据数据库的各个表，生成的各个实体类，和java中的javabean一样吧，主要都是各个字段的get和set方法
这两个程序集相信各位大哥大姐都做过，应该很简单。
然后又添加了一个程序集：
DBUtility主要内容是连接数据库，关闭，开始事物，等一些操作数据库的方法。

由DAL添加引用DBUtility，和Model

接下来，我需要做的是创建一个网站程序，于是，我添加了一个名字为WEB的网站程序
WEB添加引用了DAL和MODEL。主要是通过这两个引用，来实现对数据库的操作。

按理来说，这样的结构，其实就已经能达一个开发一个小型系统网站的目的了。

但是我发现在做的过程中遇到也一些比较麻烦的问题
1、当我再页面上需要做一些经常要做的操作的时候，比如说写日志等操作，这样我就需要建立一些类来存放这些方法（我把他们都做成了静态的）
其实这样也行了。
2、这样也行了，但是还有个问题，我需要这样的操作很多，于是我认为这些东西应该是对业务的处理，当多次操作数据库的时候，都写在一个方法里面会使得这个方法处理的业务

很单一。。所以我就将这些类单独的拿出一个程序集，取名为BLL，添加引用DAL,和MODEL，
我认为这里面的类就代表了程序的业务。。当然也定义了一些常量类，不知道应该放再网站里，还是BLL里，因为BLL我要用到，所以，我将他放在了BLL里面
同时WEB添加引用BLL，就也可以用到常量类了。

当然我也知道，像DAL根据数据库生成的这么多的类，显然不适合，当数据库表比较多的情况下。。
所以又单独拿出来了个程序集，专门用于生成SQL语句的类，再DAL中，只留下一个类，该类中所有的sql语句都由这个SQLFactory拼出来。。
当然Model应该也可以由一个什么东西替这些繁多的实体类。。这个到不是问题。

现在我很疑惑，我这样的项目结构应该算是三层的结构吗？我认为是，我有数据层，业务层等，并且我尽量多的使我的代码精简，复用。。
而且考虑的问题很多，比如像这种常量类应该放在BLL中吗？还是应该写到配置文件中？不写到配置文件中，是因为我担心配置文件的效率，因为我不了解配置文件是在什么情况下

使用的，只有在读取的时候才会被用到吗？

我尽可能的使用简单，白话般的语言描述我的问题。希望各位大哥们也能用直白的语言来给我一些建议和意见包括批评，诚心的希望能够从中受到启发，谢谢！
希望各位朋友能够顶上去，让后来的，新学习的朋友能多多的得到些收获。谢谢！

41 个解决方案

#1

自己顶下。谢谢！

#2

顶！谢谢楼主分享！其实在写程序过程中，都会有自己的见解，每个人的见解往往都不同的。虽然本人学习ASP，JAVA不久，发现它们的架构都有这不同的优点，如果能够游刃有余应用和借鉴这些架构和分层，那就无敌了。
   谈谈我对三层架构的见解吧，我觉得三层架构在数据库设计上看中表间的联系，尽力满足主与子的关系。在功能上对用户要有一定的限制，不要表现在对于子表的删除操作一定要慎重，以免造成主表与子表的数据在逻辑上出现的主表的外键在子表中没有相对应的值。在代码方面，三层架构可以减少很多重复。
   这是我在完成项目所获得的部分见解，可能对于那些大侠来说只是皮毛，待指点。

 

#3

"暂时是使用工具生成的DAL，MODEL"是什么工具啊？

#4

好吧,这次我不谈耦合不耦合的问题,连物理分层都没分好,更谈不上逻辑分层了.

你现在搞了这么一大堆东西,连基本的重用问题都没解决:

1、你是根据table生成代码的吧，那么如果有100个表，你是不是要有100个类啊，
业务实体可能会有成百上千个，这很正常，所以需要存储的表的数量是根据实际需要来的，
但是业务实体的种类怎么也不会有100个吧，20个就已经很多了。

#5

三层是一种思想，并不是说必须按照这样做。就像你自己所说的，后来发现层越来越多，这也是很正常的。越是大型的项目，分的就可能越细。

#6

引用 3 楼 heishanyaodao 的回复:

"暂时是使用工具生成的DAL，MODEL"是什么工具啊？

代码生成工具啊！

#7

什么叫做BLL？

假设我们根本不考虑c/s的情况，只考虑单机，那么BLL中的方法可能经常是这样：

static public class BLL
{

    static public List<商品> 查询多个客户都买过的商品(List<long> 用户IDs, TimeSpan 时间段)
    {......}

    static public void 提价(List<long> 商品IDs, double 幅度)
    {.....}

这跟什么实体类有多大关系？

#8

如果你在一个楼已经被民工用钢筋水泥搭建起来了，你来问“对这个楼搞设计有什么用？”，这很难回答，或者如果我是老板我根本不屑于回答。因为楼已经搭建起来了。你总是假设给你足够的时间你就能拼凑起所有底层对象，然后诘问“我都拼凑起底层对象还需要设计吗？”。

这就是症结，是意识，而不是技术。设计是驱动力，而不是你拼凑出来的。你先根据一种或者多种客户端对同一BLL功能的需求来设计所需要的接口。假设我们现在Run，肯定会发现编译错误。然后哪里编译错误我们就实现哪里。然后再Run，肯定会发现业务逻辑错误，因为我们只用方法实现了接口而方法内部是空的。于是哪里出现错误我们才实现哪里，这个时候才想到了实体、数据库。

纠缠于实体、数据库，本末倒置。可能你一直在比较简单的东西上炫耀“技术”，但是这时候你忘记了时时刻刻应该从需求出发忘记技术。

#9

当你很有节奏性地处理好BLL开发，那么你的DAL相关的开发就不一定纠结了，那一种方式都可以，只要它适合你的BLL开发就可以了。

#10

這個還真的得自己來理解。
只要適合你自己的就行···

#11

“层”的目的是让底层发生变动的时候，上层建筑纹丝不动（这是软件开发和搞建筑最大的不同）。那么你就应该经常变动底层，就像做有风险的游戏一样，以此来检验你的层的稳定性。例如删除几个数据表、或者干脆从SQL Server切换为excel作为对象存储机制。

#12

引用 4 楼 microtry 的回复:

好吧,这次我不谈耦合不耦合的问题,连物理分层都没分好,更谈不上逻辑分层了.

你现在搞了这么一大堆东西,连基本的重用问题都没解决:

1、你是根据table生成代码的吧，那么如果有100个表，你是不是要有100个类啊，
业务实体可能会有成百上千个，这很正常，所以需要存储的表的数量是根据实际需要来的，
但是业务实体的种类怎么也不会有100个吧，20个就已经很多了。

顶~

#13

现代软件设计最大的特点，就是需要应对千变万化的需求，即使在你的产品上线前1天也可能有新的需求。因此软件设计是以BLL逻辑为驱动的，对这个进行管理和测试（这里有很多软件工程技术），而把底层的技术的探讨留给少数象牙塔里边的人（可惜现在大多数学生只知道探讨底层技术）。

#14

“层”的目的是让底层发生变动的时候，上层建筑纹丝不动（这是软件开发和搞建筑最大的不同）。
这句话很经典

#15

多谢楼主分享,学习中,迷惑中,4楼说到俺心坎里去了,俺确实是根据table生成的,所以就出现model中出现大量的类(不光model中呢bll,dal也是,呵呵,生成工具都这样的),那到底该怎么处理像那样的上千种业务需求呢,学习

#16

继续说啊！！

#17

呵呵，貌似很多此类帖子

#18

引用 7 楼 sp1234 的回复:

什么叫做BLL？

假设我们根本不考虑c/s的情况，只考虑单机，那么BLL中的方法可能经常是这样：

static public class BLL
{

static public List<商品> 查询多个客户都买过的商品(List<long> 用户IDs, TimeSpan 时间段)
{......}

static public void 提价(List<long> 商……

哈哈,老大终于肯贴出点代码来了,大家可不要走宝啊!

#19

引用 15 楼 zlj002 的回复:

多谢楼主分享,学习中,迷惑中,4楼说到俺心坎里去了,俺确实是根据table生成的,所以就出现model中出现大量的类(不光model中呢bll,dal也是,呵呵,生成工具都这样的),那到底该怎么处理像那样的上千种业务需求呢,学习

就是真正站在业务的角度去分类,无论是驱动器、模型还是视图，种类都不会很多，
这是个渐进的总结归纳的过程，在这个过程中，类库会不断积累、健壮，
那么项目代码的重用度也会越来越高，直至代码总量不再随着项目的规模增加

#20

不要为单纯的三层而三层

#21

学习三层架构中~~~~

#22

  看  大话设计模式  的第一章节  的那个关于计算器的例子。

  如果我看完了，虽说不能完全撑握 三层，   但你对那个三层的思想/认识，绝对有很大提高。

  到网上去搜~，那个例子，代码不多，文字不长；但就是相当的有针对性。

#23

 
  就是这一个  http://xiaoer-1982.javaeye.com/blog/499019

  它里面就有Bll / 唯独就是没有讲到 dal...我相信你把那个bll看懂了，dal就自然懂了

#24

哎。。。

#25

封装、继承、多态

#26

说实话，其实我到不是想刻意的在项目中去使用三层，只是我想明白这里面的原理
当然我也知道现在我这样的设计也存在很多的缺陷，我相信也有很多人有跟我存在一样的问题
可我就是不明白如何设计，现在我也是感觉自己是在拼凑代码，需要什么就做什么

想真正的去学习三层，学习理论，该如何设计？，是应该从BLL开始还是应该从DAL开始？

#27

引用 4 楼 microtry 的回复:

好吧,这次我不谈耦合不耦合的问题,连物理分层都没分好,更谈不上逻辑分层了.

你现在搞了这么一大堆东西,连基本的重用问题都没解决:

1、你是根据table生成代码的吧，那么如果有100个表，你是不是要有100个类啊，
业务实体可能会有成百上千个，这很正常，所以需要存储的表的数量是根据实际需要来的，
但是业务实体的种类怎么也不会有100个吧，20个就已经很多了。

根据表结构生成实体类，我认为这样确实会生成很多的类文件，但是现在我还没有找到更好的有效的办法
能说说具体的物理分层吗？

#28

引用 14 楼 simonezhlx 的回复:

“层”的目的是让底层发生变动的时候，上层建筑纹丝不动（这是软件开发和搞建筑最大的不同）。
这句话很经典

我也认为这句话很经典，但是为了上层建筑不懂，而动底层为的就是切换数据吗？

#29

引用 7 楼 sp1234 的回复:

什么叫做BLL？

假设我们根本不考虑c/s的情况，只考虑单机，那么BLL中的方法可能经常是这样：

static public class BLL
{

static public List<商品> 查询多个客户都买过的商品(List<long> 用户IDs, TimeSpan 时间段)
{......}

static public void 提价(List<long> 商……

很多不懂！

#30

请楼主仔细研读 4、7、8、19楼回复

#31

 学习 4 楼。、

#32

三层是一种思想，并不是说必须按照这样做。就像你自己所说的，后来发现层越来越多，这也是很正常的。越是大型的项目，分的就可能越细。

#33

帮顶！！！！！！！！

#34

猜测这个帖子会被加精不?

#35

引用 34 楼 starfd 的回复:

猜测这个帖子会被加精不?

不会被加精，上面还有一个一样的帖子。

#36

期待这个

根据表结构生成实体类，我认为这样确实会生成很多的类文件，但是现在我还没有找到更好的有效的办法
能说说具体的物理分层吗？

的具体答案

#37

楼主已经很懂得三层了，很谦虚哦。

#38

我感觉现在我这样做确实是在拼凑代码，并不是设计
sp大哥的话有点深奥。理解不太明白，感觉是说要从设计出发
在代码实现过程中再去做设计的工作是没有意义的。

#39

引用 19 楼 microtry 的回复:

引用 15 楼 zlj002 的回复:
多谢楼主分享,学习中,迷惑中,4楼说到俺心坎里去了,俺确实是根据table生成的,所以就出现model中出现大量的类(不光model中呢bll,dal也是,呵呵,生成工具都这样的),那到底该怎么处理像那样的上千种业务需求呢,学习

就是真正站在业务的角度去分类,无论是驱动器、模型还是视图，种类都不会很多，
这是个渐进的总结归纳的过程，在这个过程中，类……

从需求出发吗？我也稍微看过一点的设计模式，看的不多，感觉是根据事物抽象出来共同的东西然后向下衍生。
用工具生成出来的代码，我也认为有些不过，所以在后期，DAL我只留下了一个类，但是Model我真的没有什么办法解决。。我清楚好的设计不应该是这样的，代码应该简化，业务应该清晰，能够使代码重用，并且能够写出执行效率高的代码才是好的设计。难道这就是三层的内容吗？

#40

真是有些糊涂了。。
回过头来看sp大哥的话，意思是设计业务，回过头来设计DAL,
是感觉有些道理

#41

IT领域内的大忽悠是最多的。
写你的代码就好了，写多了，就明白3层是啥意思了。