3层应用程序体系结构中的域层是否应该包含UI层所需的数据层类？

Question

假设“标准”3层应用程序（UI - 域 - 数据），Domain Layer是否应显示最初在Data Layer中定义的UI类？

我的意思是，假设在Product中定义了一个Data Layer类，从我的Domain Layer中获取某些方法返回它的方法是错误的（这是让它们可见用户界面）？或者我应该在Domain Layer本身定义一些包含Product Data Layer的类，因此UI现在不依赖于Data Layer？

由于

Answer 1

您通常拥有Product界面和ProductImpl。 UI只知道接口，并且与数据层（使用实现类）完全分离。

Answer 2

这种实现将UI类绑定到通常有害的数据类。在所有已知场景中更好的做法是将它们分开。这不仅可以将它们彼此分离，而且还可以自由地在UI类和数据类之间插入自定义逻辑（将来的任何时间）。它还使您可以自由地对数据对象进行自定义，而不会直接影响UI类。

Answer 3

这取决于您的架构。例如，如果您正在使用MVVM模式（Model-View-ViewModel），则必须在中间定义UI模型类。

Answer 4

这个问题的答案在很大程度上取决于域层的确切作用。

如果域层中几乎没有逻辑或没有逻辑，则在90％的情况下，不需要使用数据层中定义的不同对象。

如果你有一个简单的产品类，它只包含在数据层和UI之间传递数据的值等等，那么使用它们应该是非常安全的。如果域层执行了很多额外的处理，并且数据层的某些对象部分不应该暴露给UI，则只需要小心。

您应该做的一件事是为您的数据层定义一个接口，并且只能使用此接口，因此您可以使数据层独立，并在需要时在不同数据源之间快速切换。

Answer 5

在概念上，UI所需的属性是从数据层中保存的属性派生的，但它们与它们不同。我们丰富了数据，例如添加参考数据或派生值，或者组合来自不同类别的项目，或者可能使数据非规范化以使其更容易呈现。因此，在最一般的情况下，UI数据模型和持久性数据模型是不同的。

在非常简单的情况下，特别是我在演示代码中所做的事情，两个模型之间几乎没有区别，如果你创建了一组新的类，你最终会完全重复。我认为在这种情况下，Andreas_D关于创建一个定义UI所需内容的接口以及最初可能由数据层直接实现的接口是一个很好的折衷方案。它非常明确地表达了用户界面的兴趣和数据层的责任。

Answer 6

是产品域类吗？你如何获得UI层的产品类？你真的是指三层吗？层是物理边界，因此3层意味着UI / BL / DB是三个不同的过程。

如果您使用Product作为域类（= data + logic），则不应与UI共享它，而应创建新的数据传输对象（DTO）。 DTO仅在两层之间传输所需的信息。

如果您不与带有UI的Product域类共享程序集/包，而是从WSDL创建新类，则可以在公开的服务中使用Product域类 - 序列化将仅传输数据而不是逻辑。

如果您使用Product作为数据的纯容器，那么您已经创建了DTO，并且您可以在层之间与此类共享程序集/包。