随着 LINQ 的临近发布，独立数据访问层的必要性需要重新进行评估了。它是否仍是应用程序设计的一个重要部分？或者它是否会变成一个过去的附属物？
重要的问题是 LINQ 让数据访问层和业务层的界线变模糊了。Kris Vandermotten 在一个包含两篇帖子的序列文章中，通过试验基于 LINQ 的数据访问层，来讨论了这个问题，使用 LINQtoSQL 来创建数据访问层。
在他的第一个试验当中，Kris 从数据访问层中创建和返回了一个查询。Kris 讨论了一些其中涉及的问题，总结如下：
- 不像传统的数据层，在这样的设计这下，查询实际上是在业务层中执行的。
- 业务层具有重新定义查询的能力
- 层之间的界限不清，迫使开发人员要做出类似把“order by”语句放到什么地方的选择。
我讨厌让开发人员在日常开发工作中做出类似这样的选择。选择是需要时间的，并且这样的选择似乎也没有提高生产力。但是更坏的现实是，不同的开发人员将会做出不同的选择。甚至一个单独的开发人员也可能在不同的时间做出不同选择。这会导致在代码中前后矛盾。开发人员将需要花费很多时间来理解他们正在阅读的代码，仅仅由于这些代码没有一直按照同样的方式编写。对于生产力这是很糟糕的。在最糟糕的案例中，开发人员会重写每一行别人的代码，仅仅因为这些代码不符合他们在今天的选择。这对生产力是致命的（这也何谈 Linq 来提高生产力呢？）
Kris 最终得到一个结论：
我很想说对于所有情况只需做出一次明确和简单选择的唯一途径，就是使用非常抽象的方法。当然，那样意味着我们不需要 / 编写 / 使用一个实体访问层。业务逻辑直接访问一个由 SQLMetal 生成的程序集。
Adam Herscher 也研究了 LINQ，但得出完全不同的结论：
那么，在看完整篇文章后，并花了一些时间大致研究之后，我可以有把握的说，我们得到的结论表明 LINQ 是一个有前途的技术，它在未来很可能减少在设计、实现和维护一个数据访问层过程中大量的开销，虽然它今天还不是银弹。我们或许以某种功能（比如：查询 SQL 的语法辅助工具）把它合并到我们的系统中，但它也可能通过抽象出一套数据访问机制，来在现在或未来满足数据访问的需要，这些数据很可能会被缓存、分割或被多个组件 / 层来访问。
虽然可以肯定 LINQ 将会改变.NET 应用程序编写的方式，不过社区需要有足够的时间来让设计模式达成一致。
查看英文原文： Do You Need a Data Layer?
暂无签名
中国开发者画像洞察报告 2022
本次报告为你深度解读开发者人群背景，分析开发者群体面临的挑战，洞察开发者人群特征，预测开发者生态发展...
评论