如何在 ASP.NET MVC 和实体框架中扩展模型？答案

【问题标题】：How can I extend the Model in ASP.NET MVC and Entity Framework?如何在 ASP.NET MVC 和实体框架中扩展模型？
【发布时间】：2010-11-20 22:42:50
【问题描述】：

在我的第一个 ASP.NET MVC 应用程序中，模型是表和类之间的简单 O/R 映射，由实体框架管理。

现在我想为这个骨架添加一些内容，并为生成的类介绍业务方法。在 ASP.NET MVC（使用实体框架）中推荐的方法是什么？我最喜欢的是也可以在服务层中使用的解决方案，没有 ASP.NET MVC 引用，因此相同的域逻辑也可以在桌面客户端中重用。

从技术上讲，我认为即使需要刷新 O/R 类，也应该可以以保留额外业务逻辑的方式扩展生成的类。（不过，这更多是与实体框架相关的问题。）

编辑：非常感谢您的贡献，以及有关下一版本实体框架 (4.0) 的信息。构建两组类，一组是自动生成的，用于表示持久层中的数据，另一组用于实际的业务逻辑。

【问题讨论】：

【解决方案1】：

在 MVC.Net 中，模型是定义最不明确的部分。在我看来，它基本上是应用程序的其余部分（即与视图或控制器无关的任何内容）。您的应用程序的 O/R 映射部分也应该在“模型”之外，因为这更像是一个数据层。模型应该真正处理业务对象并创建数据视图以传递给视图。

对此有很多不同的看法，但我认为最好不要将 MVC.Net 视为传统的 MVC 架构。

【讨论】：

我是否正确理解您建议使用单独的“业务对象”层次结构创建业务逻辑，然后将其映射到 O/R 框架提供的“数据对象”？
这是一种做法。我认为有很多方法。不过，我确实认为 O/R 映射层应该与业务逻辑分开。
EF v1.0 对 POCO 的限制是这里的一个问题，将在即将发布的 v4.0 中解决。
J.W.，我完全不同意。如果您必须将业务逻辑塞进实体中，则没有 POCO 是一种限制。如果您按照 Jimmeh 的建议使您的业务逻辑完全独立，那么您可以使用 LINQ 将您的实体投影到业务对象上。 BO 是真正的 POCO，而不是 100% 成员声明为公共虚拟的代理基地。
克雷格，我明白并同意你的观点。如果我理解正确，您想在 Entity Framework 创建的那些实体类之上创建另一个 BO 层。对我来说，如果我可以直接从实体框架中获取 POCO，那将是一种更清晰的方法，因此我不必使用其他层。

【解决方案2】：

如果您现在使用的是 EF v1.0，实体框架会非常侵入您的应用程序，这意味着您无法轻松创建 POCO。扩展模型的方法是使用部分类。因此，当您刷新模型时，您所做的部分类仍然有效。 Entity Framework 团队意识到这是一个问题，并在下一个版本（EF V4.0）中对此进行了改进。

NHibernate 更加友好，允许您轻松扩展业务逻辑。

我真的认为 Jeremy D. Miller 的这个博客 post 非常擅长指出问题。

【讨论】：

【解决方案3】：

将您的业务层抽象到另一个项目中，然后使用结构映射之类的东西将其实例传递到您的 mvc 控制器。然后，您可以从控制器调用此业务层以检索您的业务实体（模型）并将它们传递给 UI。这将允许您在桌面应用程序中重用业务层。

【讨论】：

【解决方案4】：

这个项目不仅可以添加肉类，还可以添加一些衣服和样式，使其看起来很别致。这取决于您为该项目准备的时间。如果你有时间，我建议你看看 TDD 以及可以与 TDD 一起使用的框架，例如 Castle、NUnit、Moq 等。

正如您所提到的，服务层对于任何项目来说都是必须的，但是使用这些框架，您可以将您的架构设计得更加健壮。

【讨论】：