这是一个非常非常基本的问题。
假设我今天想在 .NET 中构建一个具有 n 层架构的企业 CRUD 应用程序。我应该使用什么数据访问方法？我想要互操作性，所以数据集已经过时了(我想现在也不再是 2003 年了)。同样，.NET RIA Services 所宣传的通过附加服务向非 Silverlight 客户端公开其功能的方法似乎也不太convincing用于更新操作。我有点能够与 Entity Framework 拼凑一些东西，它没有n层支持OOB，因此需要大量奇怪的反射类型的东西来模拟乐观并发的外观( MSDN 杂志中的 example 看起来并不支持乐观并发。我 hear 这在 EF4 中得到了改进，但我有点怀疑，除了在 CTP 中它还没有真正可用)。
那么，人们实际上可以在具有更新检查乐观并发性的企业 CRUD 项目中做什么呢？数据集？使用 DTO 进行 DIY，天知道涉及多少工作？它如何处理绑定(bind)数据？假设我有一个绑定(bind)到 DataGrid 的集合，我是否需要监听 CollectionChanged 来进行更改？我是否需要保留更改堆栈，以便在撤消时可以比较 PK？这似乎是一场噩梦。
其次，如果乐观并发的更新检查不是硬性要求怎么办？然后呢？
最佳答案
首先，如果您计划将来迁移到 VS2010 和 .NET 4.0，我强烈建议您研究 EF v4.0。自从 EF v1.0 发布以来，它已经有了显着的改进，并且在我看来，它是 nHibernate 及其类似产品的有力竞争者。 EF 也是 Microsoft future 许多数据计划的核心参与者，因此它不能像以前那样轻易被忽视。它或任何依赖于它的 .NET 4.0 更高级别框架应该能够很好地满足您的 CRUD 需求。
除此之外，我只是确保从业务角度来看，简单的 CRUD 方法是最合适的。从技术角度来看，CRUD 非常有意义，并且在较小的应用程序中，它通常是正确的选择。但您使用了“企业”一词，所以我很好奇您的应用程序的范围是否比简单 CRUD 所适用的范围更广。
除了拥有 20 到 50 名员工左右的小型公司之外，我还会研究领域驱动设计 (DDD) 和 SOA。如果您需要并发管理之类的东西，那么驱动 DDD 的原理应该可以很好地为您服务。 SOA 通常对于非常大的项目很有用，在这些项目中，您有许多开发团队同时处理需要彼此交互的多个项目。对于您的需求来说，这可能有点过分了，但是有一些好的原则可能仍然会有所帮助。
关于.net - .NET 中的 n 层 CRUD 应用程序的方法，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/1331620/