30

In a Multi-layer project with Domain layer (DL)/Business (Service) Layer (BL)/Presentation Layer (PL), what is the best approach to deliver Entities to the Presentation Layer?

DO => Domain Object;
DTO = Domain Transfer Object;
VM => View Model;
V => View;

Option 1:

DL => DO => BL => DTO => PL => VM => V

This option seems to be the Best Practice but also seems heavy to mantain.

Option 2:

DL => DO => BL => DTO => PL => V

This option seems not very good practice but as DTO are almost identical to the VM, we can pass it directly to the View and it's less painfull to implement and mantain.

Is this option also reliable for multiple layouts, for example, for Mobile Devices I may need less information from the BL, so I will need a diferent VM for this particular Layout?

4

4 回答 4

10

将 DTO 传递给视图就可以了。如果您需要更改或增强 DTO，请创建一个 ViewModel。一个常见的场景是添加链接。ViewModel 也可以将 DTO 引用为复杂属性。

于 2012-10-13T15:10:58.560 回答
2

如果您将拥有不同的视图，这些视图需要来自 Dto 的不同数据，听起来您可能会受益于这些视图模型的不同并将您的 Dto 映射到这些。

这背后的想法之一是允许更大的自由来更改您的视图模型，因为它不会对应用程序的任何其他部分产生影响。如果您的 Dto 在多个视图中使用，那么对 Dto 的每次更改都需要您测试每个视图。

于 2012-10-13T15:10:47.863 回答
1

对我来说，这个决定是基于我放置验证逻辑的位置。

场景#1：在视图模型中添加数据注释（在 UI 层）大大简化了编程。大多数情况下，DTO 和视图模型之间会有一对一的映射。在这种情况下，选项 1 很好。DL => DO => BL => DTO => PL => VM => V

场景 #2）如果验证未附加到 ViewModel，则 DTO 将替换为 ViewModel，并且 ViewModel 驻留在业务层中。DL => DO => BL => VM => PL => V

在验证逻辑驻留在域模型中的情况下，场景 #2 可能是完美的。许多 UI 应用程序都使用这些模型。UI 只是在列表中列出错误，由业务层给出（虽然不是非常用户友好）。随着应用程序发生业务规则更改，我们只更改域模型。同样，与数据库相关的验证可以通过 EF 自动生成（如果使用 .net），更改的范围更小。

于 2013-12-05T21:32:42.043 回答
0

在这里查看我的回复： https ://stackoverflow.com/a/14059156/1288063

你说：这个选项似乎是最佳实践，但也似乎很难维护。

实施起来可能很繁重，大部分时间只需复制几行代码，但维护肯定不会。

于 2012-12-27T18:24:07.453 回答