业务层的业务对象一定是和数据层的表对象一一对应的吗？

我们项目现在采取的方法是：

数据层依照数据表生成实体类。
业务层的业务对象继承自数据层的实体类，并不改写父类的属性（少写代码，方便开发）。

于是在UI层，实际上就可以通过业务对象访问到实体类的所有属性（实体类的属性都是public）。
这样，就给了UI层过多的权利，不可取。

但如果业务对象将父类（实体类）的一些属性隐藏（避免在UI被访问），就必须在业务对象中大量生成重复代码，实体类就变得没有存在的价值了。

我想请问一下，业务对象一定要和数据层的数据表对象（实体类）完全对应吗？

25 个解决方案

#1

完全对应还要业务层干什么，直接操作实体类算了，你的问题在于还不知道什么叫“业务”

#2

数据层依照数据表生成实体类。

这样做有一些问题。
比如：老师有很多属性，什么姓名、性别、出生、工资、任课、所带班……这些都可以做在一张表中。但是，在某一些业务中，可能只用到一小部分。如，在做考试系统时候，业务层只关心老师的姓名、任课、所带班级感兴趣。如果把整张老师表做成一个实体类，能行吗？

简单一点说，在不同的业务领域中，此“老师”非彼“老师”的情况是很正常的。
我的看法可能有一些偏激：数据库只是在涉及到对象持久化保存时候才可能用到。

#3

我一直人为没有具体业务方法的实体类不可取,比如老师这个类,我认为这个类不仅仅应该有老师这个对象的相关属性,还应有老师这个对象的相关方法。为什么要做一个只有属性没有方法的实体类，在做一个只有相关方法的业务类？
这样的设计部是面向对象的，也就是说他无法连接分析模型和设计实现，因为你看过只有属性没有方法的老师和只能做事而没有属性的老师么？
我觉得应该这样作：
class teacher
{
    public string name;
    public prelect()
    {

    }
}
而不是：
class teachermodel
{
    string name;
}
class teacherBLL
{

}

#4

class teacherBLL
{
   public prelect()
    {

    }

}

#5

不用实体类那你怎么解决层与层之间传递参数这个问题？一个方法中列出所有参数？比如添加教师：
AddTeacher(id,name,sex,brithday,...)
这样碰上几十个字段的表不疯了。实体类存在的最大意义就是打包相关参数并在层之间传递。另外不可能要求所有东西都面向对象，不面向对象就是罪过，哪个系统还不用数据库，常见的数据库就不是面向对象的。

#6

如果只是传递参数,那我门传一个包含方法和属性的对象过去会有什么缺点?为什么一定要传一个没有方法的对象过去?
比如传
class teacher
{
    public string name;
    public prelect()
    {

    }
}
和传
class teachermodel
{
    string name;
}
有什么不同?

#7

当然不用一一对应，不然依赖性也大了．

#8

zengjd(一) 你没听说过纯数据类这个词吗?

#9

我没听过啊,能不能给讲讲?

#10

我的理解是，没有行为的实体类还是有其存在的价值的，它用来描述领域的“场景”，由于
没有行为，可以理解为一个value object,便于在各层间传递。
如果业务模型比较复杂，完全可以在业务类中组合进一个实体类对象属性。呵呵。我们的actionForm经常是组合进一个实体对象的。在页面上用"user.name"来访问，当然，这个例子并不恰当，acitonForm不是业务层的东东。

#11

如果只是传递参数,那我门传一个包含方法和属性的对象过去会有什么缺点?为什么一定要传一个没有方法的对象过去?
比如传
class teacher
{
    public string name;
    public prelect()
    {

    }
}
和传
class teachermodel
{
    string name;
}
有什么不同?
--------------------------------------
你注意“在层之间传输”这句话，teacher类是所有层都用吗，如果所有的类都这样不就失去分层的意义了?

#12

请问傻强和各位高手：

如果现在，教师的实体类是下面这样：
class teacher {
    public int ID;
    public string Name;
    public CustomPose EnjoyPose;
}
那么
1.你觉得业务中的教师class应该是个什么样子呢（请推测一些业务）？
2.并且，你会如何设计，让UI控制、并且访问到这些数据。
3.你的控制器如何定义？

#13

>>请教傻强:

一个老师教一群学生，这样的实体类怎么设计？
class teacher
{
   public int id;
   public string name;
   public list strdents;
}
class student
{
   public int id;
   public string name;
}

还是：
class teacher
{
   public int id;
   public string name;
}
class student
{
   public int id;
   public int teacherid;
   public string name;
}

#14

说的都跑题了。
人家问的是：我想请问一下，业务对象一定要和数据层的数据表对象（实体类）完全对应吗？

#15

楼主你真的没理解什么是业务逻辑,你先查查实体类,业务类,数据对象的定义,要不然大家都搞不懂你指的是什么
使用当然不是和数据表完全对应,难道说完成一项实际业务只操作一个表吗?
按我的理解,数据库程序设计中,层间传递的对象大多是实体类
业务逻辑是将传递进来的实体类调用数据层方法写入到数据库中
数据层当然你也可以定义自己的类,完成真正的持久化.比如建立连接啦,执行SQL啦,返回指定数据集合啦等等

#16

业务逻辑是将传递进来的实体类调用数据层方法写入到数据库中

这句话我比较赞同。

#17

不一定

#18

对于小型的系统来说，业务层往往显得多余而累赘，但对于大型复杂的系统，业务层才真正体现出它的灵活可变性；所以不必要拘泥于小节，要看项目、系统的实际情况。
数据层要讲求一定的原子性，这样方便在业务层进行组合操作，有助于组件的重用；但对于小型的系统，数据层完成一定的综合功能，可以很大的提高系统的开发和运行效率，何乐而不为呢？

#19

但是说实话，大型项目的经验才能真正锻炼人。

#20

同一业务通常需要多个数据实体的对应

#21

层与层之前的关系有很多.要先决定业务层和数据层之间的映射关系放在哪一层(映射关系是指业务实体和数据库中的数据的一一对应关系)。如果映射关系放在数据层，哪么可以将业务实体对象作为参数调用数据层。如果映射关系放在业务层，则应该将业务层的属性作为参数调用数据层，如果参数太多，你可以建立结构，这些结构只在业务层和数据层可见。

#22

至于业务层的业务对象一定是和数据层的表对象一一对应则不一定。完全由系统本身的设计决定。
一般数据层采用表模式，即一个数据表一个对象。业务层中的对象和实际的业务相关，而不是和实际的数据表相关，所以就不可能完全一一对应了。

#23

应该是多对多的。

#24

该回复被版主删除

#25

建议楼主有空看看数据库设计中的E-R

#1