我一直在重写网站的后端，并将其转向三层架构。
我的意图是这样构建它：
Web site <--> WCF Service (1) <--> Business Layer (2) <--> Data Layer (3)
我的问题是 DTO 在这个结构中的放置。我需要使用 DTO 在业务层和 WCF 服务之间以及从 WCF 服务到使用网站之间移动数据。
在我的研究过程中，我读到了一些精彩的讨论，尽管我有点摸不着头脑：
Davide Piras 提出了一些重要观点这个帖子如果我遵循这个设计，那么我会在一个单独的项目中声明 POCO 的接口。然后，这些将由第 (1) 层和第 (2) 层实施。虽然我喜欢使用接口，但通过在 (1) 和 (2) 中声明 POCO，然后使用 AutoMapper 之类的工具来回复制它们的数据，我似乎会为自己做更多的工作。
这个帖子使用一个创建业务对象项目的系统，该项目将被所有层引用。这似乎比其他解决方案更简单，并且似乎引导我找到一个解决方案
Web site <--> WCF Service (1) <--> Business Layer (2) <--> Data Layer (3)
^ ^ ^
| | |
[ -- Business Objects Referenced here --]
我想说，这通常取决于您正在构建的项目的复杂性。对于我构建的较小项目，我跨层共享我的“实体”（它们只是简单的 DTO、带有 getter 和 setter 的可序列化数据桶），并且不太关心这一点。最大的缺点是逻辑分散在整个项目中（不仅在“业务层”）并且到处都是程序风格。这确实看起来像贫血领域模型，但随着项目没有增长太多，复杂性并没有增加。实体框架有一些模板，您可以从中构建实体（如果我没有记错的话，它们被称为自我跟踪实体？）。
对于中型/大型项目，我不会使用这种方法，而是将实体和 DTO 分开，因为它们将充当不同的角色。 DTO 的形状可能与您的实体完全不同，并且尝试在层/层之间共享它们通常会很糟糕。
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
