为什么我要远离DataSet，有哪些替代方案？

Question

我在这里找到了一个有趣的讨论：

http://www.linkedin.com/groupAnswers?viewQuestionAndAnswers=&gid=43315&discussionID=12708606&goback=.anh_43315

引用：

  

DataSet是用于编码数据层的业余解决方案......停止使用它们并学习代码！ ：）

您对DataSet的看法是什么？只是简化自定义类并与之合作？还有什么其他选择？

Answer 1

除了Snobbery之外，DataSets在具有相对简单的业务逻辑的应用程序中非常有用，并且开发人员可以控制数据库模式，这样数据表就可以匹配1：1业务对象（在这种情况下通常由DataRow组成） ）。

Martin Fowler在企业应用程序架构模式（Amazon link）中非常清楚地讨论了这一点。数据集（Fowler命名法中的Table Module）与Transaction Script匹配良好，而Domain Model需要更明确定义的类和数据库的映射器（因为业务之间的1：1关联）在这种情况下，通常无法实现对象和表格。）

DataSets / Table Module有很多限制，但它们在简单性方面具有优势，特别是如果您在.NET中工作。

一个务实的程序员将评估给定应用程序的要求，并应用最适合的模式和技术，即使它们不是最性感的。对于直接1：1映射到关系数据的简单场景，DataSet不会太糟糕。但是，他们经常这样做，并且任何依赖它们的程序员都会在更复杂的场景中遇到麻烦。

Answer 2

使用OR / Mapper的原因有很多。

主要是：

• 它为您的表生成编译时安全类型
• 通常会有一个分层区域，您可以在其中添加适当的业务逻辑和演示功能
• 细分数据访问（保存/加载，深度保存等）
• 加载FK相关对象的更简单/更好的过程（取决于框架）

我可以继续。

我建议您仔细检查您的OR / Mapper。就我个人而言，我实际上爱上了LLBLGen Pro（但它要花钱）。其他人喜欢其他人，我认为他们有点疯狂，但对他自己而言。你真正想要的OR / Mapper是：

• 灵活性
• 速度
• 分层生成
• 支持跨框架（CF等，如果相关）

请自行审核，并做出决定。

Answer 3

一个很大的缺点是DataSet是内存数据结构，这意味着消耗的内存量与您返回的记录量成线性关系（即O（n）空间复杂度）。在服务器端应用程序上，这会破坏可扩展性。

如果您定义自定义类T，则返回IEnumerable＆lt; T＆gt;从您的数据访问层，您可以高效地从数据源（例如Linq到Sql IQueryable提供程序）流式传输数据，复杂度为O（1）。

注意：如果您返回List＆lt; T＆gt;，则会出现同样的问题。或集合＆lt; T＆gt;来自您的数据访问层，因为它们也是内存中的结构。我已经看到很多人以优雅的名义这样做而不考虑可扩展性。