实体转换应该位于数据层或业务层

Question

根据我的理解，虽然数据层应该将数据技术与应用程序的其他部分隔离开来，但对我来说，这也包括模式(在本例中是数据实体)。最近，我从Patterns &Practice http://silk.codeplex.com/中查看了Silk项目，并注意到数据实体是在业务层而不是在数据层中翻译的。

我认为它的优点是避免了数据层引用包含业务模型的程序集。但是，根据我的理解，它公开公开数据实体是一个缺点，因为外部组件可能依赖于数据模式。

我想了解它们为什么在业务层中转换数据实体，以及它们的优点是什么？

我知道他们使用的是代码优先的实体框架，这样实体就没有数据技术相关的依赖关系，但是仍然有责任构建数据模型，而不是业务模型。

谢谢

Answer 1

我设想转换是在业务层中完成的，而不是在数据层中完成的，这样数据层就不需要知道其使用的所有情况。

使用当前的方法，调用代码有责任知道如何使用数据层。如果转换发生在数据层，那么它需要知道所有调用代码的情况。

这在一开始可能是非常直接的，因为在业务对象/实体和存储模式之间可能有接近1:1的映射，但这并不一定总是如此。

举个例子，一个企业的两个部门有着相似的概念.假设是一个审批工作流。Dept A调用工作流中的每个步骤为Bla。Dept B喜欢Dept A的工作流程自动化，并想要同样的工作流程，但它将其工作流步骤称为BongoBlas。业务领域的一个基本事实是，这两个工作流是相同的，而且永远是相同的，但是业务流程是这样的，即步骤有不同的名称(一些元数据字段也有不同的名称)。

在这种情况下，您可以开发第二个业务实体，它使用与第一个业务实体相同的持久性。

如果数据层负责转换，那么现在需要对其进行扩展，以处理BongoBla转换及其现有的Bla转换。这似乎有点奇怪，因为就数据层而言，这与其无关。

数据层与消费者无关。

这就是为什么数据层的使用者负责数据转换更有意义。当添加新的使用者时，只需要编写使用者代码。数据层可以保持不变。这是有意义的，因为数据层的关注点实际上并没有改变。

注:很抱歉出现上述蹩脚的示例场景。如果我想出更好的办法，我会更新答案。

Answer 2

你不能让事情完全独立，你必须做出自己的选择。但我认为最重要的是在一边进行翻译。

哪一部分可能会变的更频繁？选择这一部分，并尝试依赖它尽可能小。

because external components may be dependent of the data schema

如果您的项目数据层会发生很大的变化，那么它将是不利的。如果数据层更稳定，那么就没有问题。