大规模视频网站的计费与流量管理
本次分享将会就大规模视频网站的计费与流量管理这个话题，从操作层面细细进行讲解和分析，为系统工程师们揭示平日里我们没有关心的另一些内容。同时也希望本次分享能揭示行业中的一些“潜规则”，让互联网行业的流量与带宽管理更为开放与简洁。
本次演讲视频录制于QCon杭州2011。
新闻
该内容已经被标记书签！
标记书签错误，请重试！
你还需要数据层吗？
作者 Jonathan Allen 译者 朱永光 发布于 2007年8月27日
随着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?
译者 朱永光 是IT自由人和环境保护者，微软最有价值专家（MVP）和MCSD。
没有回复
关注此讨论 回复