Dal（带有实体框架）和模型层到 MVC

Posted 2023-02-24

【中文标题】Dal（带有实体框架）和模型层到 MVC

【英文标题】：Dal (with Entity Framework) and Model layers into MVC

【发布时间】：2013-09-18 06:46:43

【问题描述】：

首先，我将 EF 用于 Dal 层（与 MVC 分离的项目，相同的解决方案）。从 EF 的 EDMX 文件生成的模型是来自 Model 层的实际模型？？如果是这样，我如何访问这些模型以在 MVC 的 View 层中工作？我认为直接从视图访问数据层以使用这些模型是错误的，如果我用“我的模型”制作一个 Model 层并将 Dal 的模型转换为我的模型......它将被复制代码。

可能我弄错了，但大多数情况下。是代码优先的方法，我想不通。

【问题讨论】：

ORM Entities vs. Domain Entities under Entity Framework 6.0 的可能重复项

【参考方案1】：

我在本地项目中使用视图模型，在其他项目中使用模型。然后在我的视图模型的页面上放置对我将要使用的模型的引用。然后在我的页面上引用视图模型。如果这听起来像是您想做的事情，请告诉我，我可以在一些代码中进行编辑。

【讨论】：

我也这样做，但问题是：如果我将实体框架（数据库优先）放在 Dal 层中，EF 在 Dal 中创建模型。我如何在 Dal 中使用这些模型？我无法在 View 模型中直接访问这些模型。

【参考方案2】：

我可能弄错了，但对我来说，使用 EDMX 生成为您提供了可以被视为 DAL 的 DbContext 和可以被视为模型的实体。

因此，您可以直接将实体实例作为您的业务对象进行操作。通过 DbContext 对基的操作应该出现在 BLL 层中。此外，您可以在需要时实施 DTO。

当然，这假设您要使用实体框架代码生成。考虑到您的整体架构，使用 POCO 等其他选项可能更相关。

【讨论】：

如果我理解正确，我应该将 EF 用于混合层（即 Model/Dal 层）吗？如果是这样，我需要在 MVC 的层中使用该层，这对我来说听起来不太好 Controller 和 View 有权访问数据对象。

这样使用，EF确实是DAL和模型结合的混合层。我对 MVC 了解不多，但据我了解，MVC 的“模型”部分通常涵盖了系统的所有数据部分。它包括表示和操作（如检索或修改）。因此，我将其视为多层架构的模型和 BLL 层。

这都是真的，但是在一个大项目中，把所有东西都放在模型“命名空间”中是很疯狂的。即使在只使用 Controller、Model 和 View 层的小型项目中，很多人也会将 Model 放入一个与 View/Controller 不同的项目。

【参考方案3】：

您的想法是正确的，即不直接从您的表示层访问访问 DAL 中的模型。

为避免在将 DAL 对象转换为视图使用的模型时重复代码，您可以使用 AutoMapper 之类的东西，它应该在这种情况下为您完成繁重的工作。

【讨论】：

这是最好的解决方案吗？我虽然 EF 对此有更好的解决方案（就像我自己在一个单独的层中做 POCO，并通过某种方式 EF 跟踪它。实际上我观看了一个视频，一个人这样做“黑客”EF 生成的文件，但它非常非常痛苦）。对于所有在同一个项目中的小型开发，EF 很棒，但在大型开发中使用它对我来说听起来并不高效。使用关注点分离方法..因为用自动映射器做这个“修复”听起来很痛苦。你同意我的观点，还是我使用 EF 错了？

EF 有你提到的使用代码优先方法的解决方案，即你创建你的 POCO 模型，它们被 EF 透明地保存在数据库中。由于您使用的是 EDMX，我假设您正在生成基于现有数据库的类...在这种情况下，您必须使用某些东西将这些类映射或转换为 View 可用的模型（它们尚不可用，或者如果您想要保持你的 DAL 分开）。这样做的方法是创建一个映射层，而 Automapper 使这非常简单（您几乎不需要编写代码）。

IMO，在代码中处理数据库（代码优先方法）是不可接受的！这就是为什么我首先更喜欢数据库，但说真的，我会选择你的回复作为解决方案，因为你解释说“正确的解决方案”是我自己为模型层创建模型，而不是愚蠢的重复代码。之后，Abbas Amiri complemented it very well。谢谢你们！

好吧，关于代码优先方法有很多话要说，我发现它快速且更易于维护，并且通过迁移和版本控制更容易使您的数据库与代码保持同步。 . 当然，您可以使用 db first 方法做的所有事情，只是我发现它更容易，并且减轻了很多 db 维护和同步的负担。 :)

【参考方案4】：

我认为直接从视图访问数据层以使用这些模型是错误的...

没错，合适的方法是使用View Model

当您有几十个不同的值要传递给一个视图时，同样的灵活性可以让您 快速添加一个新条目，或重命名一个现有条目，成为你最大的敌人。你留在你的 拥有跟踪项目名称和值；您无法从 Microsoft IntelliSense 和编译器获得帮助。 处理软件复杂性的唯一行之有效的方法是通过适当的设计。因此，为每个视图定义一个对象模型有助于您跟踪该视图真正需要什么。我建议你定义一个 您添加到应用程序的每个视图的视图模型类。

-- Dino Esposito 的“Microsoft ASP.NET MVC 编程”

ViewModel 提供了您的视图创建自身所需的所有信息。要从 ViewModel 和业务实体传输数据，您可以使用 AutoMapper。

不要担心重复，这是两个不同的概念，应该彼此分开；它使您的应用程序易于维护。