关于ActiveRecord、领域模型以及iBatis的种种想法
首先，我想说明的这是一篇纯意识流的文章，
想到哪里说到哪里。有强烈数据结构、流程逻辑控的博友可以略过……
关于ActiveRecord、领域模型以及iBatis的种种想法
最近看了面向领域的种种争论，基于ActiveRecord的设计模式确实能将DAO（Data Access Object）对象、DTO （Data Transfer Object）对象和DMO Service （Domain Model Service Object）很自然的合并到一个继承自ActiveRecordBase的子类中。
如 DMO对象 PersonBase { public string Name { get; set; } public int Age {get; set;} public string State {get;set;} }
而后将这个Person对象加上[ActiveRecord(Table="Persons")]就成为了一个继承自ActiveRecordBase的DAO对象。
而后将其加上[DataContract]注解，就立马成为了一个可供WCF(Windows Communication Foundation)进行传输的DTO（Data Transfer Object）。到此时，这个PersonBase对象只是一个人的原型。具有一些人的属性，如年龄和姓名还有状态。但是这个时候的他还只是个婴儿，除了能设置它的属性、持久化进数据库外什么也做不了。
然后新建Person扩展自PersonBase扩展两个方法：Cry和 StopCry
Person : PersonBase, IPersonService
{
public PersonBase Cry(PersonBase person == null)
{
if(person == null)
{
this.State = "Crying";
}
{
person.State = "Crying";
}
this.Update(); //此处调用继承自ActiveRecord的Update方法来更新数据库
return this;
}
public PersonBase StopCry(PersonBase person == null)
{
if(person == null)
{
this.State = "Normal";
}
{
person.State = "Normal";
}
this.Update();
return this;
}
}
再建立Person的Interface
[ServiceContract]
public interface IPersonService
{
[OperationContract]
PersonBase Cry(PersonBase person == null);
[OperationContract]
PersonBase StopCry(PersonBase person == null);
}
此时给这个具有行为能力的Person类具有Cry和StopCry两种动作，此时通过WCF可以将此Person发布为一个Web Service或者是其他形式的WCF服务。
此时客户端也可以共享Person这个类提供的服务。
通过WCF的ChannelFactory建立一个Proxy对象，在客户端同时扩展这个对象也为Person，而且这个Person对象也继承自服务端的PersonBase，同样这个客户端的Person类同样实现了IPersonService接口
Person : PersonBase, IPersonService
{
public PersonBase Cry(PersonBase person == null)
{
PersonBase personback = proxy.Cry(this)
this.State = personback.State;
return personback;
}
public PersonBase StopCry(PersonBase person == null)
{
PersonBase personback = proxy.Cry(this)
this.State = personback.State;
return personback;
}
}
字样就实现了一个Person类从DAO到DTO再到DMO Service的功能转换。
其中的核心原则就是代码重复最小化。增加类的复用性，从而避免一个项目同时维护着Data Access Object、Data Transfer Object、以及一个Rich Domain Model Object。
此处的Domain Object是一个含有Domain Model Data和Domain Model Service的富DMO对象。
不再贫血了。而且可以端进行简单的继承和重构。如上面例子中 客户端仍然建立一个扩展自PersonBase这个POCO的Person类，而这个类同样实现了IPersonService接口，同样具有Cry和Stop这两种行为。
只是服务端的Person是通过操作类本身，然进行相关的行为。
而客户端的Person是通过WCF提供的proxy代理服务端的Person类的Cry及StopCry行为，并且需要将客户端的Person类本身通过this引用作为参数传递给服务端的Service做相关处理，再将处理结果返回给客户端。
可能听起来比较拗口。但是想明白后还是好理解的。
至于服务端的Person类和客户端的Person是两个不同的类，为何能在服务端和客户端进行传递呢？
答案就在PersonBase类。不管是服务端的Person类还是客户端的Person类都继承自公用的基类PersonBase。
而Person作为Service出现在服务端的时候，要求传递的DataContract参数为PersonBase类。根据子类能赋予给父类型引用的原则。理论上是可行的。
看到这里，ActiveRecord在面向DMO面向领域的模式中的弊病想必大家看出来了吧。
看客们看到这里也许要批评我了，我说了半天，压根就不是Domain Model的面向领域模型嘛～ 瞎搞了。
首先说说我对面向领域的编程模型的理解吧：
我认为的Domain Model 是这样的。比如对于一款进销存软件来说，对于销售人员这个销售领域。销售领域关心的是销售的价格，折扣，销售的数量，营销人员是谁。销售提成多少等等。而对于进货人员来说，它只关心进货的价格，进货的渠道，供货商。而对于财务来说，它只关心这个月的销售的金额、以及销售成本和利润等。
但是在数据库中，可能就只表现为两张表，一张是进货表，一张是销售表。
至于财务锁关心的利润，是通过数据库执行相关的SQL语句来进行统计核算，比如统计这个月的销售总额等等。
由于面向财务领域的数据并不真正存在于一个单独的财务表中。因此如果此时再利用ActiveRecord进行财务的统计的时候，这个Domain Model Object就会产生问题了，它应该Mapping到哪个表呢？
由于ActiveRecord是基于NHibernate的二次封装，Nhibernate又源于hibernate。
（PS:我对Castle ActiveRecord没有怎么深入的研究，但是我曾经参与过几个基于hibernate的项目的开发，hibernate对于自定义 Sql语句的Mapping 到 Pojo 很麻烦，甚至说是违背了hibernate的核心思想）
与此同时并驾齐驱的轻量级SQL Mapping Object iBatis却在这方面做的很好。
它能将任意的SQL查询语句映射到自定义的Pojo上（.net为Poco)。
因此，很适合我上述的进销存软件的领域模型的开发。（通过编写特定的SQL语句，用select sum(price * *discount * quantity) as TotalMoney .....诸如此类的语句，将特定语句查询得到的TotalMoney这个字段映射到比如说 AccountingSum这个类的 public int TotalMoney { get; set; } 属性上。
甚至可以通过两句sql语句的合并，同时完成某一个特定的领域行为。
如销售行为：第一句，insert into Sales (ItemName,Price,Quantity) values ('香皂', 100, 1);
第二句，update Stock set Quantity = Quantity - 1 where ItemName = '香皂';
这样的隐式SqlTransition来完成一个特定的领域行为。
所以我觉得，问题可能出在了这个上面：
无论是hibernate 还是 ibatis 都太固执了。
一个非得要面向 Table。将Table与Object绑定死（至少从默认的情况下，推荐Table Mapping To Object）
而另一个，却是没有绑定什么 Table， 但是，却什么都需要写Select xxx,yyy, * from table where xxxx = yyyy
对于简单的从一张表根据Primary Key检索出一条特定的Record都要写一大堆的SQL语句
灵活性是好，可是有点啰嗦，不能像hibernate(ActiveRecord)那样习惯大于约定。
而ActiveRecord(hibernate)又限制了太多的数据库服务器的功能。
对于大批量数据的归纳统计，SQL语句因为其内部运算优势以及相关的语句优化。它的效率要比用hibernate一条一条的遍历数据本身然后做出统计的效率高得高。
如：
decimal totalmoney = 0.00M:
foreach(GoodItem item in GoodItemQueryList)
{
totalmoney += item.Price * item.Discount * item.Quantiy;
}
和
SQL语句
select sum(price * discount * quantity) from GoodItem where ...
这两种实现方式虽然都能实现相同得功能，但是我像连新手也能看得出在性能优势上孰优熟略
首先从SqlClient与SqlServer的数据量上来看，明显第一种会在数据库客户端和服务器产生大量的数据交流
因此，在此处我像表明的是。
ibatis很好，hibernate不错。
但是如果能将两者CrossFire起来，那就火力相当十足啦。（此时我想到了我的上海Volks Wagen CrossPolo，很小很强大！）
ActiveRecord(Hibernate)把SQL Server服务器的功能只用了一般，或者说，大多数用Hibernate的人受其核心思想影响，不自觉的利用了其少部分功能。
而iBatis虽然能淋漓尽致的将Sql Server的威力发挥出来，但是代价就是需要声明的东西太多。
对于大的团队来说，可能有专人负责SQL语句的撰写和优化。
而对于像我这样的独立开发者来说，这无疑是一种磨难，一种很痛苦的开发体验。
（试想下：你开发周期的半数时间，都在不停的敲打select from where insert into values update set where delete where，而把更多的本应应用于领域开发的时间荒废了。）
what's more，这样对于敏捷型开发很不好。
what's more and more , 根据hibernate思想写出来的Poco对象又是跟 数据库 Table有关的一一对应的Mapping关系
也就是说，用了ActiveRecord以后，你所写出来的类，基本只属于DAO而无法像我上文所说的
让它更成为Data Transfer Object , Domain Model Object。还有，你浪费了客户花了上万元买的 MS SQL Server 或者是Oracle服务器，因为你没有让他们发挥全部的功能，你让他们偷懒了！
希望在我写完此篇日志后，能有高人写一套 ActiveRecord + iBatis 的 Combo DAO (Data Access Object ) Model框架，我想我会第一个，很乐意的去用它，哪它存在N多的Bugs，但我想，应该是一件很伟大的作品！
Time flies ， 一晃凌晨2点多了。
洗洗睡了
"