听起来很美，不是? 到今天大家还纯洁的相信Rows->Entities就是解决之道，代表了基于数据库的软件如何表现面向对象的精髓； 顽固而勤奋的寻找一个又一个的方案， 希望自己的设计水平能够一次又一次的进化，最终能够正确处理好两者之间的关系。不得不说一句，这种生硬的处理方式，要是能没矛盾，倒稀奇了。
DTO能够让IDE提供足够的信息， 能够让编译器做出适当的检查，可即使是Rich Object，在ORM负责的这一段，能发挥的真实作用也不过仅此而已. 到底有啥必要去ORM? 业务逻辑本身什么时候要求所有的数据都要变成对象了? 我们想清楚没有， 到底需要的是什么能力， 想要解决什么问题? 在进行手工的或者自动化的ORM的时候，我们到底是在寻求帮助，还是在添加障碍?
这么多年来，谁说这种方式不对，谁就被当菜鸟； 最后受益的真不知道是所谓的高手们呢，还是各种厂商。 C#这些语言中纯粹面向对象的部分， 不得不说，正在误入歧途。 制造一个麻烦，解决它，然后再制造一个。 也许这样，所有的厂商和程序员都有饭吃， 很好很强大。
即便是伟大的无与伦比的面向对象，要想不受束缚的去设计，就必须隔断数据库和业务逻辑的关系； 这不能是添加一个数据操作层或者ORM去隔断，当咱们这么做的时候，实际上恰恰是在建立一种强联系。 最可笑的是，哪怕最清晰明了的模型，也会变得复杂起来。看看CommunityServer这么一个Web系统几年来的所谓进化吧，里面的一个又一个的死对象不断的浮肿起来，带来了多少不必要的繁文缛节和沉重负担。
一个PetShop，作为一种展示无可厚非，可它又让多少人不得不在所谓的n层之间的接口上徒增烦恼呢？在我看来，什么狗屁解耦，整个PetShop，就是Linus说的围绕一堆“漂亮对象”建立起来的坚固堡垒，想要把箭楼换个位置? 除非你是秦始皇。 我一直反对Linus愤青式的言辞，但不得不说，是所有面向对象爱好者和一部分所谓“经典范例”，给了他们这些人口实。
真正的自由和解耦，是视角和思想上的分离： 我们写下的每一行代码，都应该只基于上下文相关的概念，而不是任何形式的接口。这样需要变动的，就只剩下接口与概念之间的适配物了； 同时我们获得的就是真正意义上接口的自由： 从数据库/表/字段这些接口的变化，到这些数据可以转化为的任意一种对象所体现的接口的变化。
在Linq大行其道的今天，这篇东西有点战斗檄文的意思，就不发首页了。我现在想法还很不成熟，但是深切感觉到这方面问题的兄弟们，如果你愿意了解我在这方面的想法，我一定想办法逐渐把它清晰化，一点一点的呈现出来。