2

需要迁移一些 asp.net mvc 3 应用程序模块的建议：现在我们正在使用带有 POCO 类的 EF，但将来对于一些性能驱动的模块，我们需要迁移到 ADO.NET 或其他一些 ORM 工具（可能是 DAPPER 。网）。

我们现在面临的问题是：我们的视图依赖于通过 EF 加载的 Collection 类，我应该使用什么策略来加载这些实体类，与 EF 使用其他 ADO.NET 或 ORM 工具的加载方式完全相同.

我想要的是能够在 EF 和 ADO.NET 之间切换，而数据访问层的更改最少，因为我不希望我的视图因此而生效。

4

3 回答 3

2

到目前为止我所看到的，从一个 ORM/DAL 到另一个的无缝过渡是一种错觉。Kevin 建议的存储库模式是一个很大的帮助，甚至是一个先决条件（+1）。但尽管如此，每个 ORM 在领域层都有自己的足迹。使用 EF，您可能会使用虚拟属性，可能是数据注释，或者很容易被遗忘的验证框架，它很容易适合（并忽略其他不适合的）。您可能会依赖 EF 跨连接表进行映射的能力。由于 EF，您可能不会（但愿意）做一些事情。

（更不用说在 EF 上下文之上执行脚手架的工具了。这会使锁定更加紧密。）

在你的情况下我可能会做的一些事情（如果我为你说明显而易见的事情，请原谅我）

  • 最佳使用 EF。（最好的映射，最好的关联，......）为未来做准备是好的，但它很容易退化为YAGNI模式。
  • 精通 linq + EF：有很多方法可以不必要地扼杀 EF 的性能。假设 EF 足够好！
  • 继续寻找高性能的替代方案，例如使用存储过程、并行化、后台处理和/或减少数据量，并在需求（功能性和非功能性）足够明确时选择一种。
  • 也许现在引入一个带有 DTO 的抽象层来为您的视图服务，并且将来可以很容易地由另一个 ORM 或 ADO 实现。
  • 将 POCO 公开为接口，以后可以由其他对象实现。
于 2012-04-10T20:47:54.173 回答
2

您应该使用存储库设计模式来隐藏数据访问层的实现。无论您在后台使用什么数据访问层，存储库都将返回相同的 POCO 并具有相同的操作合同。现在，如果您使用的是没有用于延迟加载的虚拟方法的真实 POCO，则此方法可以正常工作。您将需要显式处理实体上依赖集合的加载以使其工作。

于 2012-04-10T12:22:09.533 回答
0

只是添加到这两个答案...

我总是将我的解决方案构建到这些基本项目中：

  • 前端（通常是 asp.net MVC web app），
  • 具有业务流程的服务/核心，
  • 具有应用程序模型 POCO 和通信接口的对象- 被所有其他项目引用，因此它们用作数据交换合约和

  • 实现从对象返回 POCO 实例的存储库的数据

  • 前端引用对象和服务/核心

  • 服务核心引用对象和数据
  • 数据引用对象
  • 对象不引用任何其他对象，因为它们是领域应用程序模型

如果前端需要任何额外的 POCO，我会在前端创建它们作为视图模型，并且只看到该项目（即注册过程通常使用具有比Objects.User实体（POCO）更多（和不同）属性的单独类型。不需要将这些类型放在Objects中。

纯数据类型也是如此。如果需要额外的属性，这些类通常继承自同一个Objects类，并添加额外的属性和方法，例如ToPoco()准确知道如何从数据类型映射到应用程序模式类的泛型方法。

更改 DAL

因此，每当我需要更改（正如@GetArnold 指出的那样）我的数据访问代码时，我只需要提供一个使用不同库/框架的不同数据项目。所有其他特定于数据的类型等也是它的一部分......但是与其他层的所有通信都保持不变。

除了创建新的数据项目，您还可以通过更改存储库代码并在其中使用不同的 DAL 来更改现有项目。

于 2012-04-11T10:58:30.887 回答