通过图层传递类型

Question

我在解决方案中有三个层次：数据访问（DA），业务逻辑（BL）和WCF契约逻辑（CL） - 当然按顺序堆叠。

在DA中存储一个实体框架模型，其中包含一个类型形式的SQL表。我希望在CL中的层堆栈中访问这种类型，但是我不想犯下错误的实践并让CL直接与DA通信，而是将CL转换为BL并将BL转换为DA - 如果这有意义的话

最简单的方法是合并BL和CL层，但假设我想在我的解决方案中保留指定的分离，我怎么能实现我之前所说的呢？

我考虑过以下解决方案：

1. 将DA中的类型继承到BL中以创建新类型。
2. 在CL中创建一个新接口作为BL中新类型的手动模板。
3. 使用界面在CL中创建新类型。

上述解决方案的问题是，如果DL中的类型发生更新，则CL中的接口不再成立，可能会破坏应用程序。我想要一个自动更新所有图层而无需人工干预的解决方案。



有什么好听的建议吗？

Answer 1

解决方案可能是拥有第四层：模型层。此模型包含您要用作POCO类的所有类。由于它们是POCO类，因此它们不依赖于EF。如果需要，您可以使用DataMember和DataContract修饰它们。这不是最好的解决方案，但如果您认为DataContract是Serializable的替代方案，我认为这不会破坏抽象或泄漏它（当然您可以将其提升到一个新的水平，写序列化代理，但这是相当多的工作）。请注意，模型不依赖于WCF，因为这些类型位于System.Runtime.Serialization程序集中，而不是ServiceModel程序集（当然，也不依赖于EF）。

从DAL引用模型。在DAL中，您可以创建EF DbContext（禁用延迟加载和代理生成），使用流畅的API添加EntityTypeConfigurations，依此类推。

然后继续从BLL和契约层引用它们。

通过这种方式，您可以拥有一个带有POCO类的统一模型层，除了可疑的序列化属性外，它还与技术无关。

Answer 2

Three tier layer + dto

您需要实现将在所有其他层中引用的第四层（例如：公共层）。您将在其中定义您在整个应用程序中使用的类型。

Here 是一篇很好的文章，解释了你可以使用的不同方法。

Answer 3

不要实施您详细说明的3个选项中的任何一个。 正如上面的人已经指出了一个包含DTO或Pocos的Common Assembly，以及可能被所有层使用的Interface契约。

我建议在图层之间的接口中使用DTO或Pocos，以及在周围穿梭数据。 一个好的文档，有很好的例子 https://docs.microsoft.com/en-us/aspnet/web-api/overview/data/using-web-api-with-entity-framework/part-5