分层开发的一点想法

[lsfv00011]

一直按照petshop的分层来写．
但是写到后面，让别人用的时候自己很心虚．
比如一个工作人员表的model层．
public class lx_worker
{
public lx_worker()
{}
private int _id;
private string _w_name;
．．．


　　　　　　　　 public lx_worker(int id,string w_name)
{..}

　　　　　　　　　public int id
{
get{return _id;}
}．．．
｝

那么 lx_worker myworker=new lx_worker();
代表什么？一个没有意义的对象在程序中充斥着这种代码．
如果不小心，比如没有 myworker.w_name=...给工作人员添加名字．这样的操作．就进行插入操作．那肯定是出问题的。字段很多要一个一个检查．
所以感觉应该privite lx_worker()
{}
默认的构造函数应该去掉．
而去使用自定义函数
public lx_worker(int id,string w_name)
{..}
让　实体类都是有意义的类．

所以这也就让我们　dal　层添加数据的方法，不能再是　
void add(lx_worker myworker)
因为添加的时候．都没有一个有意义的实体．都是默认构造函数的实体．
我感觉应该 myworker add(string name){}结果是返回一个有意义的实体．


还有比如有些字段是不能更改比如用户登陆名字．这个就必须是只读的。如果存在一个默认的构造函数．那么new　了之后．那些只读字段怎么办？只读只能是初始化副直的．


分层写代码，按照一个表，一个实体对象的写法．总会有些操作感觉哪里有问题。
比如工作人员表格．又添加了一个工作人员更详细的表格，比如worker_detail
那么我们删除工作人员的时候，并没有把工作人员的详细信息删除．
（当然，数据库有级连删除会一起删除，但那属于数据库设计．不代表程序设计）

所以一个表对应一个实体又是不合理的。
以　woker组合detail　新加一个类．
goodworker
{
privite worker;
privite detail
}

而对应的方法　删除　．就是
del(int id)
{
(事务处理)
dal.detail.del(id);
dal.worker.del(id);
}

这又有一个问题．如果和工作人员的信息又有新的添加．比如工资信息．
那么我们又必须频繁修改goodworker的model和dal层．



感觉应该有些还是组合和接口会比较好点．
//model
public class workermodel
{
属性

workermodel(...)自定义构造函数
{
}

}


interface iworkeraction
{
del
{}
}

//dal
class worker:iworkeraction
{
//构造函数用model的构造函数
workermodel myworker;

worker(.....)
{
workermodel(...)自定义构造函数
}
overwriter del()
{}
}

//bll
abstruct abworker:worker
{
继承基类，
组合内部对象的方法　形成给外部的方法
}

程序中：abworker myworker=new worker(．．．．．)
myworker.del(..)

不知道这样用会不会以后修改起来会比较好点。
自己感觉在平常的小程序中。这样还是会稍嫌麻烦．

[hlp912]

学习

[M_arlboro]

来看看。。

[hawk_e2e]

唉，一个普通的信息化需求都出现在技术上左右为难，
看来petshop真的不怎么样。

[以专业开发人员为伍]

我不讨论具体理论了，给出结论：

1. 对象通常需要至少具有一个无参数的构造方法，而且往往这就够了。这不是什么“无意义”，而是最底限。如果你发觉“这样的操作．就进行插入操作．那肯定是出问题的。字段很多要一个一个检查”，那么为什么不深化改造你的“插入操作”机制呢？例如我可以假设你Add方法会首先判断参数object是否有接口

public Interface ICheckObject
{
void BeforeAdd();
void AfterAdd();

void BeforeUpdate();
void AfterUpdate();
}

如果有，它会首先调用对象的BeforeAdd方法然后才保存对象，这样你的lx_worker 实现这个接口就可以在BeforeAdd中首先验证所有字段的输入值合法性，如果发现异常也会清楚些报告到底是哪一个属性异常（因为这是lx_worker 里边自己的代码，当然知道属性名）。我相信你有这个能力而且也需要写验证字段代码，并且在自己写抛出异常的代码中清晰地在Message中写明字段名，而不是“一个一个检查”。

2. 如果登录名不能修改，难道就一定不能在new一个对象时设置么（此时你怎知是修改而不是初始化）？与1.类似地，你可以在BeforeUpdate中检查到修改了登录名时抛出异常，这更符合逻辑。也就是说，不是在new对象时约束不能修改登录名，而是在实际Update的时候去约束，这才符合逻辑。

3. 关于对象触发问题，特别是新的工程中如何注册以前的项目中的对象的触发器，参考我的帖子《谈谈ORM触发器设计》。

[lsfv00011]

to:sp1234
谢谢你的意见．
就是有一个问题．因为默认构造函数会提供默认直的．
我实现一个check的接口．如果此类中的属性都给出了默认直．我怎么去判断？
name．我可以知道string为空，一定没有赋直．
但是比如　int　level　默认是０．而且，确实level在程序中可以为０．
这个我就检查不到了。


to yutian130
一个表一个类，是需要　．
我的意思是相关的表，可以把他们综合起来再多一个类．．而这些类在bll层不实现，只有综合起来的类才在bll中实现．
这样相关表的操作．比如　del．就不是每个表来提供．而是这个综合的类来提供。综合的类调用下面类的单个方法．
并提供类之间的操作方法．由综合类来提供统一对外接口．

[MicrosoftCenterOfHN]

mark

[过河石头]

关注

[变成熊猫你就老实了是不]

一个表一个实体虽然不是ORM必须的，但如果数据库设计正确，建议这么做。
“继承基类， 组合内部对象的方法　形成给外部的方法 ”类似于策略模式，是个不错的东东，赞成！

[yutian130]

一个表一个类也没什么,要关联多个表可以在BLL层实现,不一定要在DAL层

[以专业开发人员为伍]

2.中也就是说，假设登录名不能修改到后台数据库，并不是说class中的登录名属性就不能set，不要搞混。

new一个对象，然后set它的登录名属性以及其它需要改变的属性，此时此对象并不影响它接下来是作为Add还是Update处理，其实都是可能的。