有些想法是以前没有表达清楚的， 在这个帖子里唠叨两句。
1. 关系模型和对象之间的矛盾， 其实很多时候找出真正的重点甚至本质的钥匙在于， 不同的阶段之间如何连接， 和比如性能之类的看似比较外围的点。
现在有一种比较不好的说法， 比如机器越来越快， 性能不重要了， 等等。 如果真是如此， 其实很多矛盾就根本不存在。 比如， 即使我们采用的是面向对象数据库，或者某个超级强大的ORM框架；也许在某些特别合适的情况下我们可能少做很多工作， 但是我们承担的起那个开销么？ 注意， 我这个不是对面向对象数据库性能的质疑那么陈词滥调， 而是这样： someBody.Friends， 关键的问题在于， 什么时候载入Friends的数据？ 载入多少条数据？ 延迟加载对于很多系统是不能接受的， 因为在这些场景中(比如压力很大的系统中， 比如数据库服务器和应用服务器之间的网络开销)， 由于连接次数过多， 带来的性能下降很可能是致命的。 而这些问题如果一旦产生， 一般就是本质性的， 任何工具也解决不了的； 即使明天CPU突破100Ghz了， 网卡响应速度提高1000倍了， 这个问题也仅仅是被隐藏一时而已。
在这里引入一个个人的认识， 我觉得应该作为每一个软件开发人员都知道的公理： 硬件的进步是为了让用户获得更好的体验， 老板降低更多的成本， 而不是为了让软件开发人员活得更舒服一些。
如果不存在这个问题， 那么一个简单的ORM或者ActiveRecord就足够了， 也不见得非得要什么面向对象数据库或者非常复杂的框架。 实际上， 正是面向对象数据库， 或者类似的理念(包括一些ORM）， 在他们的模型上， 或者其使用方式上， 往往和真实发生的事情相矛盾； 也就是说， 我们之所以碰见问题， 不是因为我们的持久化系统与面向对象不对付， 而恰恰是因为我们把不对付的做法， 带入了系统的设计和构造， 带入了应用， 所以才制造出问题： 明明因为性能也好， 因为什么其他看起来不那么关键的问题也好， 我们在这里实际上有两个阶段(持久->内存，内存->应用)， 而当我们使用一些解决方案（非工具之罪）时， 却经常性的非要罔顾这一点。 即使直接从用户的视角出发， 作为人同一时间能处理的信息也是有限的， 所以诸如何时载入数据、 载入多少等问题也是客观存在的。 想要还原真实世界吗？ 那么先搞清楚“真实世界”是用户相关的真实世界， 还是上帝的真实世界呢？如果希望引入一些新的工具， 就消除和避免这些问题， 鉴于理想和现实的差别， 抱怨的产生也是自然的了。
实际上， 我个人认为， 理解好这些问题， 采取任何解决方案都是可行的。 诸如ORM， 面向对象数据库之类的东西的引入， 更多的应该看重其它吸引力， 而不是隐藏和“帮助”我们去避开那些我们必须解决的问题； 很显然， 越是考虑的的清楚， 越可以自由和恰当的使用好它们。 要说更多的问题， 可能还有因为某些解决方案带来僵化的可能性； 因为很多时候我们希望持久和应用是可以分别变化的（不是指Oracle->MSSQL）。 实际上， 如果我们将面向对象数据库或者ORM的结果， 当作进入下一阶段之前准备的数据， 那么持久和应用之间还是解耦的。 最后归根结底， 如果我们认为存在或部分存在两套对象是不能接受的， 那不还是因为上述提到的问题吗？
最后多说一句， 在探讨这些问题之前， 首先确定你需要一打子对象。 水蒸气对象的引入， 本身就不会有什么好果子吃； 这时候引入额外的工具或框架， 最好的结果不过是既没有改进什么， 也没有损失太多； 唯一的收获是，因为我们的“设计”更“面向对象”了， 所以心里很美罢了。 这种结果恰恰造成在我们最不需要对象的时候让我们似乎尝到了什么“甜头”, 以至于让我们昏头。
2. 数据库或者其它持久化的方式， 比如文件等等， 对我们设计系统还能起到什么作用？ 我们现在非常习惯于类似于web.config这样的文件了， 也经常在数据库中保存一些配置信息， 更多的呢？
很多人总再说， .NET 1.1足够用了， 个人认为这是因为看得不够远。 关键是， .NET 2.0以后， 对于语言的变革， 对于我们的设计， 到底产生了什么样的影响？ 实际上， 大多数高水平的.NET程序员， 都对这些新特性掌握的很好， 可大多数人还只是把它们当成简化工作， 或者搞些局部技巧的糖豆， 而没有真正的让它们革新我们的设计。 想像一个对象， 除了基本的数据属性， 应用delegate，我们完全可以让行为也变成一种属性， 通过不同的配置和构建过程， 我们就可以获得多态等特性， 而且比使用老掉牙的设计模式实际上要灵活的多。
更关键的， 通过对持久层的更新， 我们非常容易的就可以改变它们， 如果花半个月功夫， 做一个用于创建和配置对象的小型框架， 我们的定制能力就不再以类为单位， 而是可以细致到每一个对象的。 而且， 鉴于过去针对不同对象的流程之间也经常会出现很大的相似性， 如果我们充分考虑操作和数据的特征， 采用新的视角来规划数据和对象， 实际上， 我们对于流程的重用， 也会上升到一个新的高度。 再想想对单元测试等应用场景的改善吧， 不是很诱人么？关键是， 我们准备好了没有， 还是等着所谓的“大师”把一切总结出来， 然后我们照做就行了？
这里说一句多余的话。 Linq刚出的时候， 我给予它比其它ORM更高的评价， 我说， “它不仅仅是一个ORM”。 但是实际上， 由于MS的影响力和一些伪面向对象专家和组织长久以来营造的一些舆论导向， 我倒是觉得， Linq带来的负面影响， 可能要比它多出的那部分带来的革新要大。 我并没有看到Linq对delegate的应用启示了多少人， 但是我看到更多的人能够更轻松的在不恰当的场景下尝试Linq中那些类似于ORM的部分， 从而更加接近上面第1条中所说的陷阱。
虽然有没写完的感觉， 但是没啥更多可以说的了， 先到这儿吧。
Update:
既然是瞎写， 也不打算上首页， 就说点乱七八糟的吧。 我觉得今天老赵搞的这个推荐是有点让人莫名其妙。 联想到这两天我去和别人去进行无聊的争论， 难道夏天到了， 大家都开始浮躁了？
警告， 后面的文字我根本不想写， 如果你是敏感的人， 尤其是你原来对我还有三分好感， 你就不要看了， 赶紧点右上角的x吧。
说一个现象， 在pongba那个圈子里也是， 在这里也是， 大家只要发一个贴， 互相的称呼就都是“大大”， “牛人”， 唉....有谁还记得《神雕侠侣》最后一段， 杨过他们上山以后碰见一群家伙正在“华山论剑”。 说实话， 有一阵子我心里很不把金庸的写作水平当回事， 觉得他塑造的太典型了， 不具备足够的技巧。 也许，生活里有些时候， 事情就是这么典型的。 我的偶像， 当之无愧的大神(相对于满世界牛人， 我觉得“大神”这个称呼也有点不够用了)John Carmack曾经说过， 跟任何程度的程序员， 都有可能学习到东西， 而不要去计较谁更“Better”， 这种精神是我非常认同的。 谦虚谨慎， 尊重他人， 这是我们都应该努力做到的， 不过现在这阵势， 还是在这八个字的正常范围内吗？ 尤其让我难以接受的是， 一些全民皆牛的参与者， 还是我曾经比较喜欢的家伙。
难道是我太敏感了？ 毕竟， 如果我不是和谐的一分子， 说不准真有问题的就是我。 看看吧， 何必非以不受人欢迎的面目出现呢。