logo标签列表

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

c#javaarchitecturen-tier-architecture
3
假设一个“标准”的三层应用程序（UI - Domain - Data），Domain Layer是否应该显示在最初定义在Data Layer中的UI类中？
我的意思是，假设在Data Layer中定义了一个Product类，从Domain Layer中的某个方法返回它们（这样，使它们对UI可见）是否有误？还是应该在Domain Layer本身中定义一些包装来自Data Layer的Product的类，使UI现在不依赖于Data Layer？
谢谢
可能有点晚了，但是我还是来说一下：我的做法是创建一个模型，例如在你的情况下是产品，作为一个单独的项目，这是一个 LinqToSql（数据上下文），这个项目可以被 UI、领域模型和数据层引用——这样可以避免编写 DTO，我认为保持简单不过度复杂是最好的！ :P - Haroon
6个回答
6
通常情况下，你会有一个名为Product的接口和一个名为ProductImpl的实现类。用户界面(UI)只知道这个接口，与数据层(使用实现类)完全解耦。
但我的问题是，UI难道不应该只使用来自领域模型的接口/类吗？ - devoured elysium
很难说 - 我知道一个大型的三层应用程序，其中接口是数据访问层的一部分（它们使用DTO模式）。因此，在这个应用程序中，UI客户端与数据层松散耦合 - 这绝对不是我喜欢的，因为服务数据层几乎总是会影响整个应用程序直到UI。 - Andreas Dolk
我不明白。UI和数据层不应该是松耦合的吗？ - devoured elysium
2
这种实现将UI类与数据类绑定在一起，通常是有害的。在所有已知的场景中，更好的做法是将它们分开。这不仅可以使它们彼此解耦，还可以让您自由地在UI类和数据类之间插入自定义逻辑（随时在未来），并且还可以在不直接影响UI类的情况下对数据对象进行自定义操作。
所以，这个想法是UI层甚至不知道有一个数据层，对吧？ - devoured elysium
绝对。这就是抽象的原因。 - Tushar Tarkas
0

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

0
这个问题的答案很大程度上取决于领域层确切的功能。
如果你的领域层几乎没有或没有逻辑，在所有情况下有90％，则无需使用数据层中定义的不同对象。
如果你有一个简单的产品类，仅保存用于在数据层和UI之间传递数据的值，那么使用它们应该是非常安全的。只有当领域层进行了大量额外处理并且数据层对象的某些部分不应向UI公开时，才需要格外小心。
你应该做的一件事是为数据层定义一个接口，并仅使用此接口进行操作，以便使数据层独立并在需要时快速切换不同的数据源。
0
在概念上，UI所需的属性来自数据层中持有的那些属性，但它们并不与它们完全相同。我们丰富了这些数据，例如添加参考数据或派生值或将来自不同类别的项目组合起来，或者可能对数据进行去规范化以使其更易于呈现。因此，在最一般的情况下，UI数据模型和持久性数据模型是不同的。
在非常简单的情况下，尤其是在我演示代码中做的那种事情中，这两个模型之间几乎没有区别，如果你创建了一组新的类，你只会得到完全重复的结果。我认为在这种情况下，Andreas_D提出的关于创建接口定义UI需要什么的观点是一个很好的妥协。它非常清晰地划分了UI的利益和数据层的责任。
UI的属性不应该来自数据层，而应该来自领域/模型层，对吗？ - devoured elysium
@devoured 是的，没错。有几个派生级别。在极其简单的情况下，数据一路上都是相同的。 - djna
0

Product是一个领域类吗？如何在UI层获取Product类？你真的是指3层吗？一层是物理边界，所以3层意味着UI/BL/DB是三个不同的进程。

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

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

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

网页内容由stack overflow 提供, 点击上面的
可以查看英文原文，
原文链接