是用Entity.Save()，还是用DAL.Save(Entity e)

       自从上一次写关于ORM的文章已经是几个月前的事情了，在这里先贴一下文章的地址，如果大家感兴趣的话可以去看看。

1、支持差异数据保存的数据库实体类设计——处女作

2、支持差异数据保存的数据库实体类设计(二)(续)

3、支持差异数据保存的数据库实体类设计(三)(续)

4、SAS框架问世（本片博客即将登场）

由于一直忙于框架的优化，所以就很少写文章了，本文也是在不断的优化自己的ORM过程中诞生的，好了废话不多说了，下面步入正题。

       一直在使用公司内部使用的一个框架，框架的的数据层可以说是两个类，一个Entity类，一个EntityFactory类，这两个类分别是干吗就不多讲了。在不断编码的过程中总是发现在重复的写EntityFactory.Save(e)、EntityFactory.Delete(e)这样的代码，心里就在想可否做一下处理，直接调用Entity.Save()，或者Entity.Delete()这样写起来方便，看起来也很顺眼。

       直到最近在优化自己的框架代码的时候，才发现Entity.Save()是不太合适的，特别是当你的应用程序需要连接到多个不同的数据库的时候，而且你也不知道当前这个Entity对应于哪个数据库，或者说同一个Entity对应于多个数据库的时候，使用Entity.Save()操作估计就很难办了。

       假设：MSSqlDAL是Sql Server数据库的数据层，在保存实体对象的时候，你可以通过下面方法完成(Entity e)

1. MSSqlDAL.Save(e);
2. 或者你在Entity中增加一个方法public void Save(){ MSSqlDAL.Save(this);}，然后调用e.Save()。

       两种方法视乎都可以达到效果，但是现在如果我们的系统需要在另外一个数据库存一个副本，即同一个对象会存到两个不同的数据库（可能是SqlServer，也可能是Oracle），这个时候，我们需要增加一个Oracle数据库的数据层OracleDAL.所以如果这个时候来调用e.Save()方法就出现问题了。

最后总结一下，最终定下来采用Dal.Save(e)保存对象是正确的，因为强制性给实体对象增加一个Save()方法，似乎有点说不通，因为对象本身并没有保存这个动作。而是由数据层来负责保存数据库实体对象，这也符合OO原则。

ASP.NET开发技术交流群： 67511751