设计模式 / 当OO遇到了持久化？！

去看看《企业应用架构模式》吧，这方面主要是ORM了，属于架构模式，而你看的那两本书属于介绍设计模式的。

ORM是我最烦的了，对我来说基本没什么用处。

不知道如何回复你好！无题吧

我试过用OO的方式来设计我现在做的项目里的一个部分。
有一个作业单，有四种情况会使用（以后可能还会有扩充），这四种情况填写的信息都差不多，90%的字段（或者交属性吧）都是一样的，但是有几个是不一样的，有几个只在一两种情况下会填写。

对于这样的业务需求，用OO的方式怎么来设计呢，又如何持久化了（就是说数据库如何设计，如何对应）。

1、基类、子类（继承）方法。
把四种情况里共用信息提出来放在基类里，在派生出来四个子类，分别对应四种情况。

2、模版方法。
把所有的信息都放在基类里面，然后再由子类决定用哪个，不用哪个。

这样想对吗？

这个作业单有40多个字段（属性、信息），分为几个部分：客户信息，派工情况，
出发、到达时间及地点，维修情况，费用情况，确认、评分情况。
四种情况里几乎每个部分都会有不相同的地方。

是设计成一个类还是多个类？

还有其他的要求没有说呢，比如，一个作业单不能完成任务的话还要添加另一份作业单，而这两个或多个作业单合起来才能完成一个任务（就是说要有联系）。
作业单还会生成附属信息，这些都是要关联在一起的，关联的地方怎么处理呢？
在类里面作关联吗？
那就是一个很复杂的大类了。

头都大了。

显然你的问题不是“设计模式”就可以解决的，因为设计模式关心的是代码层面的设计问题。而你提到的问题涉及到需求分析、系统设计等方面的知识技能。从我的感觉来看，你要想提高水平并真的解决这一系列的困惑，除了设计模式以外，你至少还要精读下面三本书《UML与模式应用》、《企业应用架构模式》、《敏捷软件开发：原则、模式与实践》。

其中《敏捷》174页有一段话应该可以回答你的问题：“数据库是实现细节！应该尽可能地推迟考虑数据库。有太多的应用程序之所以和数据库绑定在一起而无法分离，就是因为一开始设计时就把数据库考虑在内。请记住抽象的定义：本质部分的放大，无关紧要部分的去除。在项目的当前阶段数据库就是无关紧要的，它只不过是一项用来存储和访问数据的技术而已。”

显然，你是从数据库出发去看待整个系统的。OO观察的不是DomainObject的字段，而是它的行为。这些作业单有多少个字段，是不是有几个字段不同这个不是问题，得从业务逻辑上去观察它们是否有不同的行为。
简单的来讲，如果这些不同的字段并不会对业务逻辑产生影响，只是一些附属说明的话，那它们完成可以作为一种附加信息存在而不必为其编写不同类，CS就有类似的实现。

作业单的情况不了解，打个 User 的比方吧，在一些业务系统中，可以会有不同的角色，比如说管理员，会员之类的，它们就具有一些共性，但又具有不同的行为(管理员具有管理会员的行为，会员具有下订单的行为)。那么就可以作一个User基类，再派生出Administrator和Member等的子类。这样子的架构就简单清晰不易出错了。当然这也是简单情况，若需运行时扩展的话就需要更加灵活的权限系统来应对了。

合理的Model设计，ORM都能帮你解决持久化的问题，反之，则要考虑设计是否合理。

总而言之，试着去观察DomainObject的“行为”吧。

感谢各位高手的解答。
还要看那么多的书呀？项目不等人呀。没把法，还是先用我熟悉的方式来做吧。

我确实是先数据库的。数据库是不重要的，但是同时也是重要的。

最终数据是要放到数据库里的。

OO给我的感觉是：客户——>表单——>实体类——>处理——>ORM——>ADO.net——>数据库。

可能中间的部分还要多。

而我现在的做法是：客户——>表单控件生成的页面<——表单控件——>ADO.net——>数据库。