BT

如何利用碎片时间提升技术认知与能力? 点击获取答案

你还需要数据层吗?

| 作者 Jonathan Allen 关注 527 他的粉丝 ,译者 朱永光 关注 0 他的粉丝 发布于 2007年8月29日. 估计阅读时间: 3 分钟 | 如何结合区块链技术,帮助企业降本增效?让我们深度了解几个成功的案例。

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

评价本文

专业度
风格

您好,朋友!

您需要 注册一个InfoQ账号 或者 才能进行评论。在您完成注册后还需要进行一些设置。

获得来自InfoQ的更多体验。

告诉我们您的想法

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我
社区评论

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

讨论

登陆InfoQ,与你最关心的话题互动。


找回密码....

Follow

关注你最喜爱的话题和作者

快速浏览网站内你所感兴趣话题的精选内容。

Like

内容自由定制

选择想要阅读的主题和喜爱的作者定制自己的新闻源。

Notifications

获取更新

设置通知机制以获取内容更新对您而言是否重要

BT