关于三层架构的商讨

Question

在一般的项目中，架构的划分是：
1： Web
2： Entity
3:  Bll
4： Dal
5： Utility一般情况下，Entity定义的类文件属性与表是一一对应的，其对象在Bll与Dal之间传递。
那有没有这种设想？ 几乎每个Entity层的类都有一个Save ,Update 方法，我把这些方法
不写在Bll\Dal 层，而是直接写在每个类的 Entity层。比如：
PersonInfo info = new PersonInfo();
info.Name = "xx";
info.Sex = "男";
...
info.Save(this);//*****注意这一句这样写:  info.Save(this)会不会破坏三层架构呢？？欢迊一起交流。
另外，因为每个Entity层的类都有一个共用性的行为:Save ,Update,
所以，我想定义一个接口，让他们继承.

Answer 1

分开好一些，我认为。
Entity 面向对象 数据库表实体，Dal 操纵接口类。如果 Entity 里面写方法，那就不需要Dal了吧。BLL直接掉Entity，我认为问题也不大，看习惯吧。我考虑，分开好，因为我用的代码生成器是分开的，呵呵~

Answer 2

在没分层之前，OO的软件就是将对象的属性和方法都写在一个类当中的，呵呵现在倡导分层了，你这样做显然是使时代倒退了~hoho

Answer 3

Petshop、Duwamish 只是为了展示.NET强大，只是个例子，不一定非要分的跟它们一样细。

Answer 4

楼上的我同意，至少如果你能确定只使用某一种数据库产品的话，就不用使用工厂模式动态加载适当的DAL程序集了，呵呵

Answer 5

fattycat(最爱胖猫) -----------------------------有什么好笑的，有的红星还比我信誉低呢，看下面帖子http://community.csdn.net/Expert/topic/4142/4142507.xml?temp=.6661341

Answer 6

---我是楼上：gaoshanshan(高姗姗（姗姗来迟）) ( ) 信誉：18  2006-6-13 23:44:08  得分: 0  
    姗姗的信誉分还有提升的空间的，如果你是姓高的话，咱们上辈子可能是一家人，:)
fattycat(最爱胖猫) ( ) 信誉：100  2006-6-13 19:21:48  得分: 0  
在没分层之前，OO的软件就是将对象的属性和方法都写在一个类当中的，呵呵现在倡导分层了，你这样做显然是使时代倒退了~hoho
  如果把属性与方法定义在一起，我想，还是破坏了架构的整体性。因为Entity层有Save方法，
它需要调用Dal层数据访问,所以需要引用Dal层 ; 而一些Get方法，需要Dal层引用Entity层的实体对像.这样一来，两层互相引用，这是不可能的。因此可能会冲击架构(事实上非常简单的架构)。欢迊大家再一起讨论.