blocks|key|902039|text|这种实现将UI类绑定到数据类，这通常是有害的。在所有已知的场景中，更好的做法是将它们分开。这不仅可以将它们彼此解耦，还可以让您自由地在UI类和数据类之间插入自定义逻辑(将来任何时候都可以)。它还允许您自由地对数据对象进行自定义，而不会直接影响UI类。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|902040|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

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.

blocks|key|1650945|text|您通常有一个Product接口和一个ProductImpl。UI只知道接口，并且与数据层(使用实现类)完全解耦。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|1650946|entityMap^0|6|7|I|B|0^^$0|@$1|2|3|4|5|6|7|H|8|@$9|I|A|J|B|C]|$9|K|A|L|B|C]]|D|@]|E|$]]|$1|F|3|-4|5|6|7|M|8|@]|D|@]|E|$]]]|G|$]]

You usually have a <code>Product</code> interface and a <code>ProductImpl</code>. The UI only knows of the interface and is perfectly decoupled from the Data layer (which uses the implementation class).

blocks|key|2770858|text|这取决于您的体系结构。例如，如果您使用的是MVVM模式(+model+-View-ViewModel)，则必须在中间定义UI模型类。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2770859|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

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.

blocks|key|4179310|text|这个问题的答案很大程度上取决于域层到底做了什么。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|4179311|如果您在域层中几乎没有或根本没有逻辑，那么在90%25的情况下，就不需要使用在数据层中定义的不同对象。|4179312|如果您有一个简单的product类，它只保存用于在数据层和UI之间传递数据等的值，那么使用它们应该是非常安全的。如果域层做了很多额外的处理，并且数据层的对象的某些部分不应该公开给UI，则只需小心。|4179313|您应该做的一件事是为您的数据层定义一个接口，并且只使用此接口，这样您就可以使数据层独立，并在需要时在不同的数据源之间快速切换。|4179314|entityMap^0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|J|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|K|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|L|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|M|8|@]|9|@]|A|$]]|$1|H|3|-4|5|6|7|N|8|@]|9|@]|A|$]]]|I|$]]

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.

blocks|key|902069|text|从概念上讲，UI所需的属性是从数据层中保存的属性派生而来的，但它们并不完全相同。我们丰富数据，例如添加参考数据或派生值，或者组合来自不同类的项，或者可能对数据进行反规范化以使其更容易呈现。因此，在最一般的情况下，UI数据模型和持久性数据模型是不同的。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|902070|在非常简单的情况下，特别是我在演示代码中所做的事情，两个模型之间几乎没有区别，如果你创建了一组新的类，你只会得到完全重复的结果。我认为在这种情况下，Andreas_D关于创建一个定义UI需要的接口的观点是一个很好的折衷方案，该接口最初可能由数据层直接实现。它非常清楚地划分了UI的兴趣和数据层的职责。|902071|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

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.

blocks|key|2771087|text|是Product域类吗？如何在UI层中获取Product类？你真的是说三层吗？层是物理边界，因此3层意味着UI+/+BL+/+DB是三个不同的进程。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2771088|如果您使用Product作为域类(=+data+%2B+logic)，则不应与UI共享它，而应创建新的数据传输对象(DTO)。DTO只在两层之间传输所需的信息。|2771089|如果您不使用UI与Product域类共享程序集/包，而是从WSDL创建新类，则可以在公开的服务中使用Product域类-序列化将只传输数据，而不是逻辑。|2771090|如果您使用Product作为数据的纯容器，那么您已经创建了DTO，并且您可以在各层之间与此类共享程序集/包。|2771091|entityMap^0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|J|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|K|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|L|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|M|8|@]|9|@]|A|$]]|$1|H|3|-4|5|6|7|N|8|@]|9|@]|A|$]]]|I|$]]

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.

Assuming a "standard" 3-tier application (UI - Domain - Data), should the <code>Domain Layer</code> show to the UI classes originally defined in the <code>Data Layer</code>?

I mean, assuming there's a <code>Product</code> class defined in the <code>Data Layer</code>, is it wrong to make some method from my <code>Domain Layer</code> have methods returning it (this is, making them visible to the UI)? Or should I define in the <code>Domain Layer</code> itself some class that wraps the <code>Product</code> from the <code>Data Layer</code>, so the UI now doesn't depend on the <code>Data Layer</code>?

Thanks

Should the Domain Layer in a 3-tier application architecture wrap Data Layer classes needed by the UI Layer?

翻译质量差，导致语言生硬或混乱。

没有提供实际的解决方法或示例。

解答不清晰，无法理解或解决问题。

页面排版不美观，阅读体验差。

文章

问答

视频

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

假设是一个“标准的”3层应用程序(UI -域-数据)，Domain Layer应该向最初在Data Layer中定义的UI类显示吗我的意思是，假设在Data Layer中定义了一个Product类，那么让我的Domain Layer中的一些方法具有返回它的方法(即使它们对UI可见)是错误的吗？或者我应该在Domain Layer本身中定义一些类来包装来自Data Layer的Product，这样U

问3层应用程序架构中的域层是否应该包装UI层所需的数据层类？
EN

回答 6

Stack Overflow用户

Stack Overflow用户

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问3层应用程序架构中的域层是否应该包装UI层所需的数据层类？EN

回答 6

Stack Overflow用户

Stack Overflow用户

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问3层应用程序架构中的域层是否应该包装UI层所需的数据层类？
EN