原文：Using an ORM? Think Objects!
Author:Scott Allen
最近我在飞机上恰好有时间读完了Bitter EJB, POJOs in Action和Better,Faster, Lighter Java这三本书。它们都不错，但是我最喜欢最后这本，它是Ian Cooper推荐给我的。不，我现在不打算做关于java的开发。我读这些书是想洞察和预见java 生态系统中的特定趋势。
尽管不可能用一段话就可以概括这些书，但是我还是要试一下：
一些Java开发人员避开EJB框架是为了他们能够将精力集中在对象上。简单对象，可测试对象，易变对象和原始的java对象，它们都可以解决业务问题而不会被基础框架和技术考虑所妨碍。
以上就是我对这三本书的要点的概括。这些书同样谈到了各种模式，反模式，域驱动设计，轻量级框架，各种处理以及编写软件的一般性方法。你会改到惊奇，会有那么多的内容使用于.Net。实际上，当我读完这本书时，我就开始思考.net 和 Java 是两个平行的宇宙，它们的不同可以解释成在时间的路途中，偶然杀死的一只蝴蝶。
这篇文章的焦点就是一个独特的，确实突出的偏差。
从对象到ORM
那些专注于对象的Java开发者最终不得不和其它类似于持久化之类的问题打交道。他们对对象的关注很自然使他们中的一些尝试对象关系映射框架。像Hibernate 一样的ORM框架不仅为开发者提供了开发效率，而且还是以透明的和非注入的方式。这两者一开始就很融洽的工作，就像开发者们了解ORM，而ORM似乎也了解开发者一样。
从Dataset到ORM
.NET包含了Dataset, DataTable和DataView。IDE提供了一个数据菜单和一个带有各种各样的数据控件和数据源的tab的GUI工具箱（用vs系列的开人人员都知道）。这很容易使.net的主流开发呆板地成为以数据中心。当你向一个从未见过ORM的.net开发人员介绍ORM时，他们会问这些典型的问题：
在做完INSERT操作之后，我如何管理那些数据唯一性
或者是
这个东西可以和存储过程协同工作吗？
尽管这些问题在.net的环境中显得非常合理，但是你几乎可以在这些问题中体会到一种紧张。而这对我来说就是偏差突出的地方。在飞机上，我读到过关注对象的Java开发者们寻找各种各样的ORM。而在.net的领域中，我看见各种各样的ORM在寻找关注数据的开发人员。尤其要说的是，这些ORM，例如LINQ到SQL(这个功能，当前和Visual Studio绑定在一起发布的)和实体框架（在SP1中发布的）。任何对某些东西，例如ADO.Net 3.5有所期待的人都会感到吃惊。持久化对象和DataSet是两种不同的东西，需要两种不同的方法去思考它们。
.Net 开发人员会关注各种对象吗？
可能性倒是有，但是工具却让它变得困难。例如，实体框架在某几个点上给开发人员带来了认知上的不协调。文档会告诉你实体框架的目的是创建丰富的，概念上的对象模型，但是在新闻发布上，有说实体框架用来简化以数据为中心的开发。在实体框架中，那些单纯的，老的CLR对象将不存在，然而正在变成标准的，关注对象的隐式的懒加载又不可获得(你可以读取这个实体的任何属性，嗯，有一点，你必须首先加载它)。
LINQ转SQL又有所不同。在LINQ转SQL过程中，一路上都是对象。如果你揭开这层面纱，你可以在LINQ转SQL过程中使用单纯的，老的CLR对象。然而，这层面纱是一个闪耀的设计器，看上去就像强类型的DataSet设计器一样。LINQ转SQL的过程仍然需要额外的映射帮助的支持，只有这样才能真正地将对象模型和背后的数据库设计分开--希望我们能够在下一个版本中看见这一功能。
未来该如何做
如果你是一个正要开始使用ORM--任何一个ORM的.Net开发人员，你需要你自己和你的项目组重置各种默认情况，并且从不同的角度来思考这个新的模式。忘掉那些你所知道的关于Dataset的考虑，学习工作的单元模式。忘掉那些你所知道的关于数据读取器的知识，学习ORM的数据映射是如何工作的。遇到任何问题，要先考对象，然后才是数据。如果你不能将考虑数据放在后面的位置，ORM将不会成为你的技术。