你还需要数据层吗？

作者 Jonathan Allen译者 朱永光 发布于 2007年8月27日 下午10时10分

社区

.NET,

Architecture

主题

数据访问,

设计

标签

LINQ

随着LINQ的临近发布，独立数据访问层的必要性需要重新进行评估了。它是否仍是应用程序设计的一个重要部分？或者它是否会变成一个过去的附属物？

重要的问题是LINQ让数据访问层和业务层的界线变模糊了。Kris Vandermotten在一个包含两篇帖子的序列文章中，通过试验基于LINQ的数据访问层，来讨论了这个问题，使用LINQtoSQL来创建数据访问层。

在他的第一个试验当中，Kris从数据访问层中创建和返回了一个查询。Kris讨论了一些其中涉及的问题，总结如下：

1. 不像传统的数据层，在这样的设计这下，查询实际上是在业务层中执行的。
2. 业务层具有重新定义查询的能力
3. 层之间的界限不清，迫使开发人员要做出类似把“order by”语句放到什么地方的选择。
   

我讨厌让开发人员在日常开发工作中做出类似这样的选择。选择是需要时间的，并且这样的选择似乎也没有提高生产力。但是更坏的现实是，不同的开发人员将会做出不同的选择。甚至一个单独的开发人员也可能在不同的时间做出不同选择。这会导致在代码中前后矛盾。开发人员将需要花费很多时间来理解他们正在阅读的代码，仅仅由于这些代码没有一直按照同样的方式编写。对于生产力这是很糟糕的。在最糟糕的案例中，开发人员会重写每一行别人的代码，仅仅因为这些代码不符合他们在今天的选择。这对生产力是致命的（这也何谈Linq来提高生产力呢？）

Kris最终得到一个结论：

我很想说对于所有情况只需做出一次明确和简单选择的唯一途径，就是使用非常抽象的方法。当然，那样意味着我们不需要/编写/使用一个实体访问层。业务逻辑直接访问一个由SQLMetal生成的程序集。

Adam Herscher也研究了LINQ，但得出完全不同的结论：

那么，在看完整篇文章后，并花了一些时间大致研究之后，我可以有把握的说，我们得到的结论表明LINQ是一个有前途的技术，它在未来很可能减少在设计、实现和维护一个数据访问层过程中大量的开销，虽然它今天还不是银弹。我们或许以某种功能（比如：查询SQL的语法辅助工具）把它合并到我们的系统中，但它也可能通过抽象出一套数据访问机制，来在现在或未来满足数据访问的需要，这些数据很可能会被缓存、分割或被多个组件/层来访问。

虽然可以肯定LINQ将会改变.NET应用程序编写的方式，不过社区需要有足够的时间来让设计模式达成一致。

查看英文原文：Do You Need a Data Layer?

• 更早的 >