.NET 中 n 层 CRUD 应用程序的方法

Question

这是一个非常非常基础的问题。

假设我想在今天构建一个具有 n 层架构的 .NET 企业 CRUD 应用程序。我应该使用什么数据访问方法？我想要互操作性，所以 DataSets 出来了（我想它也不再是 2003 年了）。同样，.NET RIA Services 所宣传的通过附加服务向非 Silverlight 客户端公开其功能的方法对于更新操作似乎不是很convincing。我有点能够用实体框架拼凑一些东西，它没有 n 层支持 OOB，因此需要许多奇怪的反射类型的东西来模拟乐观并发的外表（ MSDN Magazine 中的 example 看起来不支持乐观并发。我 hear 这在 EF4 中得到了改进，但我有点怀疑，除了 CTP 之外它还没有真正可用）。

那么，对于具有更新检查乐观并发的企业 CRUD，人们实际上可以为他们的项目做些什么呢？数据集？使用 DTO 进行 DIY，天知道涉及多少工作？以及如何处理绑定数据？假设我有一个绑定到 DataGrid 的集合，我是否需要听 CollectionChanged 进行更改？我是否需要保留大量更改，以便在有撤消时比较 PK？这似乎是一场噩梦。

其次，如果乐观并发的更新检查不是硬性要求怎么办？然后呢？

Answer 1

首先，如果您计划在未来迁移到 VS2010 和 .NET 4.0，我强烈建议您研究 EF v4.0。自从 EF v1.0 发布以来，它有了显着的改进，在我看来，它是与 nHibernate 和朋友之类的强大竞争者。 EF 也是微软未来许多数据计划的核心参与者，因此不能像过去那样轻易忽视它。它，或者任何依赖它的 .NET 4.0 更高级别的框架，应该可以很好地满足您的 CRUD 需求。

除此之外，我只想确保从 业务角度 来看，简单的 CRUD 方法是最合适的。从技术角度来看，CRUD 非常有意义，在较小的应用程序中，它通常是正确的选择。但是您使用了“企业”一词，所以我很好奇您的应用程序的范围是否比简单 CRUD 所服务的范围更广。

除了拥有 20 到 50 名左右员工的小型公司之外的任何事物，我都会研究领域驱动设计 (DDD) 和 SOA。如果您需要诸如并发管理之类的东西，那么驱动 DDD 的主体应该可以很好地为您服务。 SOA 通常适用于非常大的项目，在这些项目中，您有许多开发团队同时处理需要相互交互的多个项目。对于您的需求来说，这可能有点矫枉过正，但有一些好的原则可能仍然会有所帮助。