设计中的问题--业务实体的职责

[elvahuang]

欧觉得业务实体的职责应该有数据访问的能力,因为毕竟业务中对业务实体的操作无非是增、删、改、查，不知道对不对呢?

[elvahuang]

up for me

[SimerJoe]

业务实体?
"实际业务"中的"实体"?比如定货单,陪送单吗?
还是"业务逻辑"中的"对象"?比如客户,员工等等?
这2者都来自需求中的"名词",他们最大的区别就在于一个有"动作",一个没有.
如果是前者,他们属于"静态实体"都到数据库里面去了.
如果是后,部分在数据库里面(属性),部分动作在程序运行时作为主要的逻辑(甚至接口).
在这种主要的逻辑里面不要直接或间接放数据库操作.

[elvahuang]

例如在我系统中的"申请表单"

我的想法是这样的：（具体细节略）

class ApplyForm
{
string FormName;
string FormCheckInDate;
...表单实体其余属性

//逻辑验证，如表单申请日期必须大于结束日期等
ValidFormData();

//对数据库的操作
NewForm();//将该表单新增到数据库中
AlterForm();//将该表单更新到数据库中
};

[elvahuang]

这样的话,就是将所有对表单的操作全放进表单类里面.

而对与大多数网上的例子来讲,如Duwamish，采用的方法就不是这样的

Duwamish采用的方法是将诸如NewForm操作放到DA层中，将ApplyForm类的对象作为参数穿过去
但是这样的话，一旦ApplyForm类改变的话，如加入一个属性，就会将影响的范围扩大到DA层

[elvahuang]

up again

[SimerJoe]

首先,如果是我来设计的话,我不会设计"申请表单"这样一个奇怪的类,但可能会有"申请表单"这样一个DataTable对象,因为表单有数据,但不会产生动作.

我会有表示层和逻辑层,下面看看我的设计,和这种设计在"申请表单"发生变化时的应对方式(忽略细节笼统的说一下意思.):
假设表单数据全部放在 table 这个对象里面.
逻辑层:(假设以下2个方法都在myClass类中)
方法一:针对table的数据库操作.
方法二:针对table的显示.
表示层:
属性一:DataGrid用来显示table.
方法一:向DataGrid绑定table.不是自己实现,而是调用逻辑层myClass的方法二.
方法二:添加某记录.不是自己实现而是调用逻辑层myClass的方法一.

当table的属性(及列)改变时,需要变动的只是逻辑层了.

逻辑层知道数据层和表示层的某些信息,并且负担着业务逻辑.
以上就隐藏了table的细节,如果隐藏掉逻辑层方法一和方法二的实现类myClass的细节呢?
那就是针对接口了,可以在运行时使用不同对象的同名方法来实现表示层的请求,这样就表现除了更大的灵活性,就是典型的多态性了.

[elvahuang]

tks