3 层应用程序架构中的域层是否应该包装 UI 层所需的数据层类？
假设有一个“标准”3 层应用程序（UI - 域 - 数据），域层是否应该向数据层中最初定义的 UI 类显示？
我的意思是，假设在数据层中定义了一个Product类，那么让我的Domain Layer中的某些方法具有返回它的方法是错误的吗（也就是说，让它们对 UI 可见）？或者我应该在Domain Layer本身中定义一些类来包装Data Layer中的Product，这样UI现在不依赖于数据层？
谢谢
Assuming a "standard" 3-tier application (UI - Domain - Data), should the Domain Layer show to the UI classes originally defined in the Data Layer?
I mean, assuming there's a Product class defined in the Data Layer, is it wrong to make some method from my Domain Layer have methods returning it (this is, making them visible to the UI)? Or should I define in the Domain Layer itself some class that wraps the Product from the Data Layer, so the UI now doesn't depend on the Data Layer?
Thanks
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（6）
您通常有一个
Product接口和一个ProductImpl。 UI只知道接口，与数据层（使用实现类）完美解耦。You usually have a
Productinterface and aProductImpl. The UI only knows of the interface and is perfectly decoupled from the Data layer (which uses the implementation class).这种实现将 UI 类绑定到数据类，这通常是有害的。在所有已知场景中，更好的做法是将它们分开。这不仅可以将它们相互解耦，还可以让您自由地在 UI 类和数据类之间插入自定义逻辑（将来随时）。它还使您可以自由地对数据对象进行自定义，而不会直接影响 UI 类。
This kind of implementation binds the UI classes to data classes which generally is harmful. A better practice in all known scenario is to keep them separate. This will not only decouple them from each other but also give you the freedom to insert custom logic (anytime in future) between UI classes and data classes. It also gives you freedom to do customizations to data object without affecting the UI classes directly.
这取决于你的架构。例如，如果您使用 MVVM 模式（模型-视图-视图模型），则必须在中间定义 UI 模型类。
It depends on your architecture. For example, if you're using the MVVM pattern (Model-View-ViewModel) you have to define UI model classes in the middle.
这个问题的答案很大程度上取决于域层到底做什么。
如果域层中几乎没有或没有逻辑，则在 90% 的情况下，无需使用数据层中定义的不同对象。
如果您有一个简单的产品类，仅保存用于在数据层和 UI 等之间传递数据的值，那么使用它们应该非常安全。您只需小心域层是否进行大量额外处理，并且数据层对象的某些部分不应暴露给 UI。
您应该做的一件事是为数据层定义一个接口，并且仅使用该接口，这样您就可以使数据层独立并在需要时在不同数据源之间快速切换。
The answer on this question strongly depends on what the domain layer exactly does.
If you've got nearly no or no logic in the domain layer, in 90% of all cases, there is no need to use different objects then defined in the data layer.
If you have a simple product class, which only holds values for passing data between Data Layer and UI and so on, it should be pretty safe to use them. You have only to be careful if the domain layer does much additional processing and some parts of objects of the data layer should not be exposed to the UI.
One thing you should do is to define an Interface for your Data Layer and only work with this interface, so you can make the Data Layer independent and switch quickly between different data sources if needed.
从概念上讲，UI 所需的属性源自数据层中保存的属性，但它们并不完全相同。我们丰富数据，例如添加参考数据或派生值或组合来自不同类别的项目，或者可能对数据进行非规范化以使其更易于呈现。因此，在最一般的情况下，UI 数据模型和持久性数据模型是不同的。
在非常简单的情况下，特别是我在演示代码中所做的事情，两个模型之间几乎没有区别或没有区别，如果您确实创建了一组新的类，那么您最终会得到完全重复。我认为在这种情况下，Andreas_D 关于创建一个定义 UI 需要的接口的观点，并且最初很可能由数据层直接实现，这是一个很好的妥协。它非常清楚地划分了 UI 的利益和数据层的职责。
In concept the attributes required by the UI are derived from those held in the Data layer, but they are not identical to them. We enrich the data, for example adding reference data or derived values or combining items from different classes or perhaps denormalising data to make it easier to present. So in the most general case the UI data model and the persistence data model are different.
In really simple cases, especailly the sort of things I do in demonstration code there is little or no difference between the two models and if you do create a new set of classes you just end up with complete duplication. I think in this case Andreas_D's point about creating an Interface defining what the UI needs, and which may well initially be directly implemented by the Data layer is a nice compromise. It very clearly demarks the UI's interests and the Data Layer's responsibilities.
是 Product 域类吗？如何获得 UI 层的 Product 类？你真的是说3层吗？层是物理边界，因此 3 层意味着 UI / BL / DB 是三个不同的进程。
如果您使用 Product 作为域类（= 数据 + 逻辑），则不应与 UI 共享它，而应创建新的数据传输对象 (DTO)。 DTO 仅在两层之间传输所需的信息。
如果您不使用 UI 与 Product 域类共享程序集/包，而是从 WSDL 创建新类，则可以在公开的服务中使用 Product 域类 - 序列化将仅传输数据而不是逻辑。
如果您使用 Product 作为纯粹的数据容器，则您已经创建了 DTO，并且可以在层之间与此类共享程序集/包。
Is a Product domain class? How do you get Product class in UI tier? Do you really mean 3-tier? A tier is physical boundary so 3-tier means that UI / BL / DB are three different processes.
If you use Product as domain class (= data + logic) you should not share it with UI and you should create new data transfer object (DTO) instead. DTO transfers only needed information between two tiers.
If you don't share assembly / package with Product domain class with UI and instead you are creating new class from WSDL you can use Product domain class in your exposed service - serialization will transfer only data not logic.
If you use Product as pure container for data, you have already created DTO and you can share assembly / package with this class among tiers.