3

我一直在为网站重新编写后端，并将其移向三层架构。

我的意图是这样构建它：

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 --]

我的问题是：跨解决方案的三层共享业务对象是否有代码味道，或者我上面列出的两种方法只是破解同一个问题的两种不同方法？

4

2 回答 2

2

我会说这通常取决于您正在构建的项目的复杂性。对于我构建的较小项目，我在各个层之间共享我的“实体”（它们只是简单的 DTO，具有 getter 和 setter 的可序列化数据桶），并且不太关心这一点。最大的缺点是逻辑分散在整个项目中（不仅在“业务层”中）并且到处都是程序风格。这看起来真的很像贫血领域模型，但由于项目没有增长太多，复杂性并没有蔓延。Entity Framework 有一些模板，您可以根据这些模板构建实体（如果我没记错的话，它们被称为自我跟踪实体？）。

对于中/大型项目，我不会使用这种方法，而是将实体和 DTO 分开，因为它们将扮演不同的角色。DTO 可能具有与您的实体完全不同的形状，并且尝试在层/层之间共享它们通常会很臭。

于 2012-07-17T11:29:09.630 回答
2

让我们将您的 UI（网站）和服务（WCF + BL + DAL）视为两个不同的实体。

  • 如果您对两者都有 100% 的控制权，则应该选择方法 #2，因为它将避免 WCF 代理对象和 UI 层中的业务对象之间的转换。

  • 否则，您最好使用方法＃1，因为其中一个实体是一种“黑匣子”，并且会受到外部利益相关者的更改。因此，维护一组内部业务对象更安全。这将需要在您的业务对象和 WCF 代理对象之间进行转换（通过扩展方法或转换器框架）。

现在，不完全确定您的 UI 层复杂性或其实现（MVC、WebForms 等），因此您可能需要也可能不需要 View 特定对象（数据绑定更轻，序列化为 JSON 更快等），让我们将此对象称为Model.

  • 如果您不需要特定的 UI Model，建议将您的业务对象标记为DataContract（在 WCF 的上下文中）并跨层使用它们。不要忘记显式标记实体，就Serializable好像您正在通过 Web ( $.ajax) 调用 WCF。

  • 否则，DataContract在服务和翻译器中使用DataContract以Model在 UI 层中转换。AService Adapter在这里很合适 - 它位于 UI 层，负责使用 WCF 服务并在 和 之间进行DataContract转换Model。您可以Service Proxy在 UI 层中使用 a，它是 WCF 服务的包装器，可在 Web 上使用。

最后，您是不是缺少对数据层中业务对象的引用？我相信您将从数据层本身的数据存储中填充您的业务对象。

于 2012-07-17T16:15:30.397 回答