为什么要在业务层创建实体对象？答案

【问题标题】：Why should I create my entity objects in the business layer?为什么要在业务层创建实体对象？
【发布时间】：2013-11-27 20:42:50
【问题描述】：

我有一个关于 n 层项目的问题

我正在观看一个视频课程，该课程教您如何根据 SOA 原则创建应用程序。首先，视频类是旧的，或者没有代码优先的方法。

在视频中，开发者将实体对象带到了业务层，因为在他看来，我们使用实体框架默认生成的实体对象不好。

这样，在数据层中创建的存储库，使用实体对象层模型而不是使用来自数据层的实体对象

这似乎很奇怪，如果你认为数据层依赖于业务层

这让我很困惑，因为我使用的是代码优先方法，并且我在数据层中创建了对象实体，用于映射它们和上下文类的实体框架。

我想象了以下场景：表示层 MVC 项目在业务层使用我的类。

业务层消耗我的存储库和工作单元的类

数据层实体对象、存储库、工作单元、上下文类别

那么为什么要在业务层创建实体对象呢？ ?

对不起我的英语，它的谷歌翻译器。

非常感谢！！

【问题讨论】：

【解决方案1】：

您的实体对象绝对应该是数据层的一部分，因为它们决定了数据库结构（使用代码优先方法时）。根据您的描述，该视频似乎指的是某种DTO（数据传输对象）或可能类似于ViewModel 的东西。

【讨论】：

谢谢！我需要更多地了解视图模型以及如何使用它们。我看到了一些东西，我有一个疑问。我必须在表示层中创建我的视图模型，对吧？！？！？！因为这是 MVC 的一个特性。事实上，如果我不使用 MVC 项目，我不需要创建视图模型，对吧？？？
@LéoJenkins MVC 只是一种模式，因此您想从表示层（即视图）中删除任何逻辑，ViewModels 能够做到这一点。所以ViewModels 不仅仅适用于 MVC，可能还有其他模式需要类似的东西。
@LéoJenkins 您似乎混淆了 MVC 和 MVVM 两种模式。它们都用于将逻辑与视图分离。

【解决方案2】：

在 n 层方案中，您将实体与数据访问层 (DAL) 分离成一个额外的程序集，您可以在客户端和服务器之间共享该程序集（共享程序集）。 DAL 仅在服务器上使用，而实体在客户端和服务器上使用。

实体可以是纯粹的 DTO，以便在不同层之间传送数据，或者它们可以包含业务逻辑（数据验证、计算属性、业务操作等），这将使它们成为业务组件。因此，您可以看到业务层跨越两层（客户端和服务器），您的实体是其中的一部分。

【讨论】：