随着 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?
评论