我能否直接使用Entity Framework生成的模型？

Question

我对使用Entity Framework比较新。我在一个Web MVC 2项目（.NET 3.5）上工作，并正在探索使用Entity Framework，因为我读到它是在数据访问层中推荐的方法。

我的问题是，我已经创建了我的数据库并使用Visual Studio创建了实体模型。现在，自动为我生成了一些类供我使用。我已经阅读了一些教程，他们直接使用这些类。

但是我不确定。在未来，我想需要一些额外的业务逻辑来处理我的模型。那么现在，我应该创建自己的模型类吗？

提前感谢您！

- bloodfire1004

---

如果没有必要，就不要这样做。这就是为什么有向导存在的原因，他们可以为您创建模型。而这些是数据模型，这并不意味着您不能基于它们或它们的组合在应用程序中拥有其他模型。那么为什么模型会包含业务逻辑呢？ - Sami Kuhmonen

Answer 1

我认为你的意思是，你通过设计师生成了模型。无论你使用 Code First Approach（先创建类）还是 Database First Approach，都没有关系。模型是表的表示，你可以通过 Dbcontext 访问模型，其中你的模型被表示为 DbSets。你可以根据实现的逻辑在模型/表上使用 dbcontext 进行任何类型的操作。

业务逻辑不应该是模型的一部分，而是理想情况下离其两层远。业务逻辑层应该调用数据访问层（DAL），而 DAL 应该有逻辑通过 EF 的 dbContext 访问/操作数据。

请参阅仓储模式。（https://msdn.microsoft.com/en-us/library/ff649690.aspx）

这有助于业务逻辑独立于底层数据源（无论是 SharePoint、SQL Server 还是 Web 服务），因为 DAL 层有实现来访问数据。这种方法也避免了代码重复，有助于数据集中化，并且更少容易出错。添加关注点分离也有助于更好的单元测试。

- Anjani

Answer 2

这取决于常规的开发实践。

如果你的项目非常简单，并且你确信它永远不会变得更加复杂，那么不创建业务逻辑层是可以的。

此外，在控制器中直接访问自动生成的类将使你的实现更快。

如果你没有这些确定性，我建议你创建一个业务逻辑层，并将自动生成的类仅用作将填充和持久化业务逻辑模型的数据表。

如果你不创建业务逻辑层，那么在维护和扩展应用程序时你将遭受痛苦。

- miguelbgouveia

Answer 3

你的数据模型代表数据库表。模型不应包含业务逻辑。您可以使用其他模型来组合所需的dbmodel属性。在单独的类中应用业务逻辑。 服务、存储库这些概念用于使项目更易管理。 但是，您不应在模型类中应用业务逻辑。这不是一个好的实践。

你可以从这里得到一些想法。这可能会帮助您理解。 https://softwareengineering.stackexchange.com/questions/213317/net-mvc-project-architecture-layering

- Sadid Khan