对象的持久化

对象的持久化在C++很难实现，有了反射，[Serializable] 可以实现持久化到文件的功能，但是把对象持久化到数据库里比较麻烦。
业务对象（领域对象）的持久化的功能最好在内部实现，如果比较复杂，则 把对象持久化的任务从业务逻辑中分离出来，在数据对象里实现。
当业务类和数据表的结构很一致，把持久化功能实现在业务对象里，采用Active Record模式，用ling to sql或Castle active Record 等轻量级orm实现。但是如果业务类和数据表的结构不一致，而且逻辑也变复杂了， 采用Domain Model模式。 业务对象包含了 不依赖于持久化的 的业务逻辑，数据对象处理持久化， Service层调用数据对象来实现 依赖持久化的领域逻辑。

------------------------------------------------------------------------------------

业务层需要考虑到一些与数据访问层交互的设计模式，模式中包括事物脚本模式、表模块模式、活动记录模式、领域模型模式。

事物脚本模式是通过方法来执行业务流程，它是一个过程式模型，事物脚本的每个方法都有一个特定的事物脚本，它侧重于业务上一系列流程上的顺序操作，它实现起来很简单，但是它有个致命的缺点就是它会造成很多重复的代码。

表模块模式比起事物脚本模式，具有一定的结构，它的思想也很简单，每个数据表都定义一个业务组件（实体类，实体操作类），在.NET中更多的使用DataSet作为表模型的数据交互。但是它也有一个缺点就是它是从数据库驱动它不适合于大量的数据表以及数据表之间的复杂关系。

活动记录模式中的对象中，可以包含数据和方法。它接近于数据表的结构，它的对象中执行方法中可以包含CRUD操 作，验证算法，以及其他的计算功能。一般来说，领域模型不是太复杂，活动记录模式是个好选择。当然他也存在问题，同样地，它对于复杂的业务上，维护的成本 也很高，并且如果需求变更导致数据库修改，就需要调整记录对象模型中的相关代码。

经典应用：LINQ-TO-SQL以及Castle ActiveRecord。

领域模型模式是从领域驱动设计中衍生来的，它是以业务为核心的设计模式。它对于复杂的业务逻辑，相当适用。前三种方式使用的是以数据驱动方式，数据驱动方式特点简单，但是当系统到了一定的规模后，就会到难以维护的程度。

 

数据访问层的目的很明确,主要作为提供数据持久化的功能，包括数据的读取和写入，另外还必须包括事务处理，并发控制等等。

操作数据库的方法可以有两种方式,ORM方式，ADO.NET方式。

ORM可以采用一些第三方的ORM框架来实现，ADO.NET采用ASP.NET自带的数据库操作来实现。

不同的数据库具有不同的持久化实现，因此这里添加一个存储仓库接口层，来适应不同的数据库实现，这里你可以使用IOC依赖注入方式进行数据库选型，可以利用Unity、Spring.NET、Castle的IOC容器等等。

 

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/7399830/viewspace-707359/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/7399830/viewspace-707359/