DAL“类型化数据集”或自定义业务对象答案

【问题标题】：DAL "Typed DataSets" or Custom Business ObjectDAL“类型化数据集”或自定义业务对象
【发布时间】：2010-08-30 13:30:36
【问题描述】：

我想听听您对“数据集设计器”和 DAL（数据访问层）最佳实践的意见。我使用 Visual Studio 2010 Framework .NET 4.0。

根据我的理解，“DataSet Designer”允许我使用 DataTable 和 Adapter 自动创建严格的 Typed-DataSet，这包括直接在 Visual Studio 2010 中的 DAL。

我想知道： - 如果在实际场景中“数据集设计器”运行良好，或者最好编写自定义业务对象。 - 如果存在 .net 4.0 中引入的其他新解决方案

感谢您的支持！ :-)

【问题讨论】：

标签： c# .net asp.net

【解决方案1】：

我必须使用类型化的数据集，这是一场噩梦。如果你有一个选项，永远不要使用它们。一切都变得更好了。

【讨论】：

那么你推荐使用什么？
如果不需要复杂的映射：POCO + 标准 ADO.NET 或 Linq-To-Sql。如果你需要复杂的映射 NHibernate + POCO 或 EF4 + POCO。数据集是来自 .NET 1.x 的技术。 .NET 2.0 中有一些更新，但这些更新使它们变得更糟。

【解决方案2】：

随着 .Net 4.0 框架的出现和 LINQ to SQL 的引入，我一直在采用由严格编写的业务对象组成的定制 DAL。我们对 Entity Framework 进行了短暂的试验，但最终得出的结论是，它与 DataSet 非常相似，因为自动生成的代码虽然很方便，但过于臃肿，充满了我们最终没有使用的多余垃圾。

我们发现，将 LINQ 写入 DAL 并将数据提取到我们的自定义类中，我们能够简化数据访问并在功能上控制数据的使用。这是一个非常方便的过程，但初级开发人员需要一点时间才能掌握它。

【讨论】：

+1 简要说明了一个人可能对 EF 持批评态度。事实上，它有（相当多的）缺点。就我个人而言，我仍然使用 NH，更加灵活，对 DB 没有任何影响。
您应该研究新的“代码优先”实体框架。这就像仅在 EF 中使用 Fluent nHibernate。这是非常精简的IMO。唯一的缺点是它仍在 CPT 中（目前为 4），但玩起来很酷。查看 EF 博客了解更多信息：blogs.msdn.com/b/adonet/archive/2010/07/14/…
@TheCloudlessSky - 我会看看。由于处于重大项目之间，我们仍在寻找新标准，因此感谢您的阅读。

【解决方案3】：

我建议使用ORM，例如Entity Framework 或Nhibernate。

数据集对数据库的思维方式来说太过分了，我个人在使用它们时遇到了很多问题。它们只是经常被破坏并抛出难以解决的奇怪错误。

其他一些您可能会感兴趣的相关问题

What are the advantages of using an ORM?

ASP.NET DataSet vs Business Objects / ORM

【讨论】：

【解决方案4】：

使用 ADO.NET Entity Framework，这是微软 ORM 的未来发展方向。或者，考虑一个像 NHibernate 这样的开源软件......

HTH。

【讨论】：

【解决方案5】：

在我的公司，我们使用 Typed DataSets 已经有一段时间了，并且总体上获得了积极的体验。我知道很多人不喜欢 DataSet，当然也有更新的数据访问工具，但是由于您询问的是真实场景，以下是我的一些要求和发现：

需要能够读取 SQL Server、MS Access 和 FoxPro 数据源
SQL Server 访问只能通过 SPROC 调用（不是我的选择）
相对容易学习，尤其是对于刚接触 ASP.NET 的开发人员而言

我亲自探索了低级 ado.net 访问、类型化数据集、linq-to-sql 以及简单地编写自定义数据访问类。我还没有看过实体框架，因为 VS2008 中包含的版本似乎有一些混合的评论，而且我直到最近才访问 VS2010（我确实计划在今年某个时候审查 EF）。

我们选择使用类型化数据集是因为它们似乎可以提供更快的针对 SPROCS 的开发，并且我们在 asp.net 站点上找到了 Scott Mitchell 的一个非常全面的教程：http://www.asp.net/data-access/tutorials。

就我们迄今为止的经验而言，大部分情况都很好。数据集设计器即使对于少量表（

您可能会尝试做一件事来让您的决定更容易：提出一个小的域问题，例如客户编辑页面或订单输入页面，并使用各种技术多次实施。这需要一些时间，但这是一种很好的学习方式，您可以自己比较这些技术。我们这样做了，它似乎有很大帮助。

【讨论】：

【解决方案6】：

我个人更喜欢具有灵活性但工作量更大的自定义业务对象。还可以查看 Entity Framework 和 Linq To Sql。 Entity Fx 在 .NET 4.0 中获得了更多的灵活性。这个article 应该可以帮助您开始使用 Entity Fx。

【讨论】：

【解决方案7】：

如果有什么我认为你应该看看Entity Framework。那里有 are lots 的 great 教程可以帮助您入门。

【讨论】：

【解决方案8】：

我个人有条件地同意 Joel Etherton。

如果您有一个足够小的项目，即使 EF 臃肿，您仍然没有看到太多的恶作剧代码，我会说它提供的权宜之计是值得的。然而，在更大的代码库中，解决如此臃肿的问题可能会变得很困难。

EF 与旧式业务对象相比的另一个好处是没有提到的，通过 EF 实现，您可能会更容易升级到较新的 .NET 版本，利用下一个 .NET 中的好处，而无需重写一堆代码用手。（这也可能是一把双刃剑，因为使用 EF 升级到新的 .NET 可能会影响您的 dal 的行为，而手写 dal 不太可能受到如此影响。）

也就是说，我同意 Joel Etherton 的观点，编写可以实现 LINQ 的最简单的最小 dal，dal 总是太重要了，不能在可以避免的情况下过于复杂。

【讨论】：

【解决方案9】：

如果您不想浪费时间，请不要学习 DataSet。研究对象关系映射的一般概念及其优缺点。看看像 Hibernate for Java 或 Doctrine for PHP 这样的项目。仅提供数据库对象包装的 DataTables 和 DataSets 背后的方法已经结束。您的框架应该指导您设计领域模型，而不是数据库架构。

【讨论】：

【解决方案10】：

NHibernate。特别是如果您使用的是 Oracle。

【讨论】：