我应该在我的表示层中使用实体框架实体吗？答案

【问题标题】：Should i use Entity Framework entities in my presentation layer?我应该在我的表示层中使用实体框架实体吗？
【发布时间】：2012-04-27 21:57:23
【问题描述】：

我想创建一个多层（3 层）应用程序。 EF 是首选的 ORM。

我应该使用 EF 直接在我的表示层中创建的实体，还是应该创建新的自定义实体并映射实体？如果是这样，我应该在自定义实体之上创建接口吗？

我应该将EF生成的.edmx文件放在数据层吗？

谢谢

【问题讨论】：

【解决方案1】：

我个人会为我的表示层创建 ViewModel。您希望尽可能地抽象化您的 EF 模型。

您的 ViewModel 不需要任何接口，它们只是简单的POCO/DTOs。

【讨论】：

EF生成的.edmx文件应该放在数据层吗？
你把 ViewModel 放在业务层了吗？
我这样做的方式是，我的业务层返回自定义对象，以便我可以尽快抽象出我的数据层模型。我在控制器级别创建 ViewModel（我的大部分工作是使用 ASP.NET MVC 基于 Web 的）并将这些传递给我的视图。因此，将数据直接传递到表示层的方法是我创建 ViewModel 的地方，但在您的情况下，表示层可能是创建 ViewModel 的地方。
ViewModel 进入您的 UI 层，如果您有代表业务主要概念对象的实体，这些实体将进入 BLL。 EF 将进入 DAL。假设您有一个财务应用程序，获取数据是 DAL 的责任，而这就是 EF 的职责所在。像 Account、AccountHolder 等业务实体将具有业务规则和状态，并且这些对象将通过来回传递 DTO (POCO) 来读取 DAL，以实现快速数据传输。 UI 将创建实体并将它们聚合为代表多个实体的复杂对象，这些实体成为您的 ViewModel
@JamieDixon 这也适用于 MVC。那么，您是在控制器级别（即表示层）创建 ViewModel，还是只是从控制器调用一个方法来获取必要的实体并将它们映射到 ViewModel，然后将其发送回表示层？跨度>

【解决方案2】：

数据库的需求和数据消费者的需求经常不一致，因此通常需要不同的模型。

例如，考虑添加新客户的用户故事。故事通常包括对办公室电话号码和传真号码的“需求”。

马上，数据库设计人员会说“这是重复数据”，我需要一个一对多的关系，这样我们不仅可以容纳两个电话号码，而且可以容纳几乎无限数量的电话，按类型。（我们甚至不要陷入电话号码是多对多或一对多的痛苦）

同时回到报告、屏幕、移动设备，你有什么 UI 体验——那个设计师说“我不在乎你能存储多少个电话号码，我只处理两个: 一个办公室号码和一个传真号码”你可以说用户的核心是非规范化的:)

【讨论】：

团队开发人员之间的用例问题在于，您假设团队和任务之间没有需求管理和沟通。他们都只是解决他们认为最好的任何问题，而不考虑软件必须如何作为一个整体组合在一起。
@DavidAnderson 我听到了，但困难仍然是相互竞争的问题。例如，一个 UI 只公开了底层数据提供的可能性的一个子集。问题在于调和这些相互竞争的问题。我只是建议在这种情况下，这些方、UI 和 DB 之间应该有明确定义的交互点。你想在哪里进行映射当然是有争议的，但除非你只是写一个简单的表格编辑器，否则我建议对竞争结构之间的映射进行某种排序是不可避免的。