http://blog.joycode.com/uestc95/archive/2003/11/04/5176.aspx
O/R Mapping，陷阱还是苹果？
在JAVA的世界始终在讨论的一个问题是：EJB是否欺骗了我们？当然这样的问题就好像鸡生蛋蛋生鸡一样没有定论和结果，但是不容置疑的是EJB的确不是当初我们想像的那样好，世界上本来就没有救世主，一切还都要靠自己。而在.NET世界则更是如此，都说微软提供了开发人员所需要的一切，从而使得开发人员越来越贬值，但实际情况却恰恰相反，太多的东西他都没有提供，比如O/R Mapping机制,持久维护机制等等。
使用MS提供的免费午餐带来的代价就是：你别无选择，因为你也根本没有其他的选择，比如COM+，Remoting，再比如以后的Indigo。从另外一个角度来讲，这也未尝不是一件好事情，当然前提你没有发现JAVA世界的精彩。
上面的话其实没有开始这篇随笔的主题：O/R Mapping，陷阱还是苹果？只是开始的一瞬间，思维胡乱跳跃。其实还有一个更大的延伸话题是：OO世界是否是一个虚幻的世界？当然这就不是我所能探讨的话题了，你可以和OO大师们一论高低，
.NET 2.0将会提供O/R Mapping机制的实现，你自己看看就会发现他只是在和J2EE相靠拢,当然J2EE的O/R Mapping也是在向某种东西靠拢，究竟是什么呢？你当然会说是：高效开发，提升可延展性，降低需求变化给软件设计和编码带来的振荡。没错，的确是这样的。但是这样作并不是没有任何牺牲的，那就是增加编码的复杂度和工作量，毕竟宇宙间能量是守恒的！ 是苹果还是陷阱，就要看这些牺牲是否值得了。这就不是一个是或者否能精确回答的问题了，通过精确的项目控制和人为能力，完全可以做到高效率，而不采用O/R Mapping，比如前提是不考虑多数据库支持。因为说到底，O/R Mapping机制提供的可延展性是非常有限的，他对于业务逻辑的支持基本上等于0，而我们大量的工作量都在业务逻辑部分。这也是我为什么有这样一个随笔的原因所在。我们在仔细分析了当前业务环境之后就要决定O/R Mapping是否值得去使用，如果你追求的高效率，而不是所谓的“优美设计”，那么就放弃吧。
比如我们高强度的ERP运算的时候，一定需要绕开O/R Mapping机制，否则等待我们的一定会是系统当机。而现在我发现越来越多的开发人员在刻意追求所谓的OO设计，尤其是.NET世界，虽然O/R Mapping算不上“过度设计”，但是本质一样。所有提供O/R Mapping机制的技术都会提供对象缓存技术，为什么？因为他知道这种构建实体和进行持久化的动作将会是非常耗费系统资源的，也就是说他们了解O/R Mapping所带来的问题，通过对象缓存技术来尽量抵消这个缺陷，但仅仅是“尽量”，所以我们开发或者分析设计人员更要明白的了解何时该绕过O/R Mapping!
不是说你运用OO技术和设计模式多么熟练就表明你的功力有多高，而是说做到正确辨别何时该用什么才是真正的高手。
O/R Mapping，陷阱还是苹果？
在JAVA的世界始终在讨论的一个问题是：EJB是否欺骗了我们？当然这样的问题就好像鸡生蛋蛋生鸡一样没有定论和结果，但是不容置疑的是EJB的确不是当初我们想像的那样好，世界上本来就没有救世主，一切还都要靠自己。而在.NET世界则更是如此，都说微软提供了开发人员所需要的一切，从而使得开发人员越来越贬值，但实际情况却恰恰相反，太多的东西他都没有提供，比如O/R Mapping机制,持久维护机制等等。
使用MS提供的免费午餐带来的代价就是：你别无选择，因为你也根本没有其他的选择，比如COM+，Remoting，再比如以后的Indigo。从另外一个角度来讲，这也未尝不是一件好事情，当然前提你没有发现JAVA世界的精彩。
上面的话其实没有开始这篇随笔的主题：O/R Mapping，陷阱还是苹果？只是开始的一瞬间，思维胡乱跳跃。其实还有一个更大的延伸话题是：OO世界是否是一个虚幻的世界？当然这就不是我所能探讨的话题了，你可以和OO大师们一论高低，
.NET 2.0将会提供O/R Mapping机制的实现，你自己看看就会发现他只是在和J2EE相靠拢,当然J2EE的O/R Mapping也是在向某种东西靠拢，究竟是什么呢？你当然会说是：高效开发，提升可延展性，降低需求变化给软件设计和编码带来的振荡。没错，的确是这样的。但是这样作并不是没有任何牺牲的，那就是增加编码的复杂度和工作量，毕竟宇宙间能量是守恒的！ 是苹果还是陷阱，就要看这些牺牲是否值得了。这就不是一个是或者否能精确回答的问题了，通过精确的项目控制和人为能力，完全可以做到高效率，而不采用O/R Mapping，比如前提是不考虑多数据库支持。因为说到底，O/R Mapping机制提供的可延展性是非常有限的，他对于业务逻辑的支持基本上等于0，而我们大量的工作量都在业务逻辑部分。这也是我为什么有这样一个随笔的原因所在。我们在仔细分析了当前业务环境之后就要决定O/R Mapping是否值得去使用，如果你追求的高效率，而不是所谓的“优美设计”，那么就放弃吧。
比如我们高强度的ERP运算的时候，一定需要绕开O/R Mapping机制，否则等待我们的一定会是系统当机。而现在我发现越来越多的开发人员在刻意追求所谓的OO设计，尤其是.NET世界，虽然O/R Mapping算不上“过度设计”，但是本质一样。所有提供O/R Mapping机制的技术都会提供对象缓存技术，为什么？因为他知道这种构建实体和进行持久化的动作将会是非常耗费系统资源的，也就是说他们了解O/R Mapping所带来的问题，通过对象缓存技术来尽量抵消这个缺陷，但仅仅是“尽量”，所以我们开发或者分析设计人员更要明白的了解何时该绕过O/R Mapping!
不是说你运用OO技术和设计模式多么熟练就表明你的功力有多高，而是说做到正确辨别何时该用什么才是真正的高手。
