Jimmy Nilsson谈LINQ to SQL

文章来自：

 

1.

我是Jimmy，我来自瑞典。昨天有人告诉我，我只有2个错误，一个是我喜欢测试驱动开发，而另外一个是我来自瑞典。我想只有2个错误已经很不错了。我是一个有20年经验的开发人员，目前致力于领域驱动开发以及敏捷实践。

 

2.

微软构建了一个新的框架，为 C#和Visual Basic提供了一种查询语法。LINQ to SQL是其中的附属物。你能说它是为了构建查询然后发送给数据库，但是从大的范围上来说，它也是一个对象关系映射器（object relational mapper），虽然比较简单。这是微软第一次尝试发布一个对象关系映射器。在过去他们也尝试过几次，但都无疾而终了，但是这次我想他们的确做到了。

 

3.

首先，我认为LINQ是一个美 妙的语言。我曾经尝试过创建一种通用的查询语言，但是我的东西和LINQ相比简直一团糟。我觉得LINQ很漂亮，所以在对象关系映射器中使用LINQ作为 查询语言非常不错。尽管其他一些映射器也很容易掌握和入门，更让我高兴的是，我认为这会使许多.NET开发人员开始关注领域驱动开发。

 

4.

不过我认为这种做法仍旧相当普遍。.NET社区经常只会使用微软创造的东西。大部分人都不会去使用开源的替代品。因此，许多开发人员能够突然发现一条操作数据的新方法让我非常兴奋。

 

5.

事实上，我认为最主要的问题在 于它不支持在领域模型中使用值对象（译者注：value objects，在.NET框架中可以理解为Struct类型）。在过去几年里，我越来越喜欢使用值对象。我使用大量的值对象来封装领域模型中细微的概 念。这使得那些概念意于独立测试，复用，以及表现其意图。我不能在LINQ to SQL中使用它们，我认为这的确是个大问题。除此之外还有一些小问题，例如在忽略持久化的属性时。我能够避开这些小问题，不过不支持值对象就让我有些难以 使用了。尤其对于一个像我这样从事领域驱动设计的人来说。

 

6.

有，我想出一个很丑陋的办法。 幸运的是，我能够在需要的时候加载值对象，并且将它们保存在域变量中，可惜很不幸，查询也会受到影响。我昨天对微软反映了这个情况，他们也得出了一些想 法。他们或其他一些人可能会通过深入表达式树的方式来解决这个问题，不过我们不想花太多时间来讨论临时的解决办法。我们希望能够关注领域本身，所以就目前 来说我不知道会接下来会发生什么事情

 

7.

实体框架是由另一个项目组开发 的，他们目前正在非常努力的工作着。关于这点我知道的并不太多，但是在我的印象中实体框架是个庞大的框架，而LINQ-to-SQL是一个轻量的东西。它 们都是面向数据库方向，而不是从领域知识这边得来的。而且我认为有可能实体框架在这方面会更糟糕。以我的理解，它目前完全不能忽略持久化操作。我喜欢 LINQ to SQL，因为它小而简单。

 

8.

我必须就这个问题谈一下我的看 法。我完全认为人们需要熟读《Domain Driven Design》这本书。我认为这对于过去没有使用丰富领域模型的人们来说提出了非常好的建议。另外，变成贫血模型很容易，这样只增加了成本而没有带来利 益。你们可能会遇到的另一个问题是不为领域模型添加任何行为而只进行映射。还有一个问题就是，因为创建了一个领域模型，所以任何东西都被联系在一起，这就 变成一摊稀泥了。所以我认为《Domain Driven Design》对于入门非常有帮助。

 

9.

我认为Hibernate是一 个更成熟更有能力的解决方案。你能够使用它进行更复杂的映射。例如，我用Hibernate开发了许多东西，它起了很大的作用。如果你已经使用了 Hibernate那么我想你不用迁移至Linq-to-SQL。如果你还没有尝试过Hibernate那么现在使用Linq-to-SQL是一个不错的 开始。目前有人正在创建Linq-to-Hibernate，设法把查询语言和优秀的映射引擎结合起来。

 

10.

我最喜欢的计算机书籍是Eric Evans的《Domain Driven Design》。我觉得它就像诗歌一样。它不光有优秀的内容，而且写的很棒，能够反复阅读，就像读诗一样。