大规模视频网站的计费与流量管理
本次分享将会就大规模视频网站的计费与流量管理这个话题，从操作层面细细进行讲解和分析，为系统工程师们揭示平日里我们没有关心的另一些内容。同时也希望本次分享能揭示行业中的一些“潜规则”，让互联网行业的流量与带宽管理更为开放与简洁。
本次演讲视频录制于QCon杭州2011。
技术访谈
该内容已经被标记书签！
标记书签错误，请重试！
Jimmy Nilsson谈LINQ to SQL
受访人 Jimmy Nilsson 采访人 Floyd Marinescu 翻译 赵劼 发布于 2008年3月21日 长度 00:09:09
概要
在这个访谈中，Jimmy谈论了LINQ to SQL和ORM。Jimmy曾经尝试过构建一个与LINQ to SQL比较相似的技术，但是得到了不同的结果。尽管LINQ to SQL朝正确的方向迈出了重要的一步，但是.NET在对象-关系映射方面依旧落后于其他编程语言。
个人简介
Jimmy Nilsson是一个名为“factor10”的瑞典咨询公司的合伙人和CEO。他写了大量的技术文章以及2本书，其中包括《Applying Domain-Driven Design and Patterns》。他同时还开展一些培训并在一些会议上讲话。不过除此之外，用他自己的话说，他是一个有着20年经验的开发人员。您可以通过http://JimmyNilsson.com/blog/访问Jimmy的博客。
在这个访谈中，Jimmy谈论了LINQ to SQL和ORM。Jimmy曾经尝试过构建一个与LINQ to SQL比较相似的技术，但是得到了不同的结果。尽管LINQ to SQL朝正确的方向迈出了重要的一步，但是.NET在对象-关系映射方面依旧落后于其他编程语言。
个人简介
Jimmy Nilsson是一个名为“factor10”的瑞典咨询公司的合伙人和CEO。他写了大量的技术文章以及2本书，其中包括《Applying Domain-Driven Design and Patterns》。他同时还开展一些培训并在一些会议上讲话。不过除此之外，用他自己的话说，他是一个有着20年经验的开发人员。您可以通过http://JimmyNilsson.com/blog/访问Jimmy的博客。
我是Jimmy，我来自瑞典。昨天有人告诉我，我只有2个错误，一个是我喜欢测试驱动开发，而另外一个是我来自瑞典。我想只有2个错误已经很不错了。我是一个有20年经验的开发人员，目前致力于领域驱动开发以及敏捷实践。
微软构建了一个新的框架，为C#和Visual Basic提供了一种查询语法。LINQ to SQL是其中的附属物。你能说它是为了构建查询然后发送给数据库，但是从大的范围上来说，它也是一个对象关系映射器（object relational mapper），虽然比较简单。这是微软第一次尝试发布一个对象关系映射器。在过去他们也尝试过几次，但都无疾而终了，但是这次我想他们的确做到了。
首先，我认为LINQ是一个美妙的语言。我曾经尝试过创建一种通用的查询语言，但是我的东西和LINQ相比简直一团糟。我觉得LINQ很漂亮，所以在对象关系映射器中使用LINQ作为查询语言非常不错。尽管其他一些映射器也很容易掌握和入门，更让我高兴的是，我认为这会使许多.NET开发人员开始关注领域驱动开发。
不过我认为这种做法仍旧相当普遍。.NET社区经常只会使用微软创造的东西。大部分人都不会去使用开源的替代品。因此，许多开发人员能够突然发现一条操作数据的新方法让我非常兴奋。
事实上，我认为最主要的问题在于它不支持在领域模型中使用值对象（译者注：value objects，在.NET框架中可以理解为Struct类型）。在过去几年里，我越来越喜欢使用值对象。我使用大量的值对象来封装领域模型中细微的概念。这使得那些概念意于独立测试，复用，以及表现其意图。我不能在LINQ to SQL中使用它们，我认为这的确是个大问题。除此之外还有一些小问题，例如在忽略持久化的属性时。我能够避开这些小问题，不过不支持值对象就让我有些难以使用了。尤其对于一个像我这样从事领域驱动设计的人来说。
有，我想出一个很丑陋的办法。幸运的是，我能够在需要的时候加载值对象，并且将它们保存在域变量中，可惜很不幸，查询也会受到影响。我昨天对微软反映了这个情况，他们也得出了一些想法。他们或其他一些人可能会通过深入表达式树的方式来解决这个问题，不过我们不想花太多时间来讨论临时的解决办法。我们希望能够关注领域本身，所以就目前来说我不知道会接下来会发生什么事情
实体框架是由另一个项目组开发的，他们目前正在非常努力的工作着。关于这点我知道的并不太多，但是在我的印象中实体框架是个庞大的框架，而LINQ-to-SQL是一个轻量的东西。它们都是面向数据库方向，而不是从领域知识这边得来的。而且我认为有可能实体框架在这方面会更糟糕。以我的理解，它目前完全不能忽略持久化操作。我喜欢LINQ to SQL，因为它小而简单。
我必须就这个问题谈一下我的看法。我完全认为人们需要熟读《Domain Driven Design》这本书。我认为这对于过去没有使用丰富领域模型的人们来说提出了非常好的建议。另外，变成贫血模型很容易，这样只增加了成本而没有带来利益。你们可能会遇到的另一个问题是不为领域模型添加任何行为而只进行映射。还有一个问题就是，因为创建了一个领域模型，所以任何东西都被联系在一起，这就变成一摊稀泥了。所以我认为《Domain Driven Design》对于入门非常有帮助。
我认为Hibernate是一个更成熟更有能力的解决方案。你能够使用它进行更复杂的映射。例如，我用Hibernate开发了许多东西，它起了很大的作用。如果你已经使用了Hibernate那么我想你不用迁移至Linq-to-SQL。如果你还没有尝试过Hibernate那么现在使用Linq-to-SQL是一个不错的开始。目前有人正在创建Linq-to-Hibernate，设法把查询语言和优秀的映射引擎结合起来。
像诗歌一样的《Domain Driven Design》
发表人
霍 泰稳
发表于
Re: 像诗歌一样的《Domain Driven Design》
发表人
Ye Lin
发表于
-
采访中Jimmy所谈论的这个像诗歌一样的《Domain Driven Design》，InfoQ中文站上有其精简版可下载，链接为：领域驱动设计精简版
-
这本书值得详细阅读，但要做Domain Driven Design，要有一个像Hibernate这样的ORM框架才好。
2 条回复
关注此讨论 回复