将DTO/POCO放在三层项目中 [英] Placement of DTO / POCO in a three tier project

问题描述

我一直在重新编写网站的后端，并已将其移向三层体系结构.

我的意图是使其结构如此

Web site <--> WCF Service (1) <--> Business Layer (2) <--> Data Layer (3)

我的问题是DTO在此结构中的位置.我将需要使用DTO在业务层和WCF服务之间以及从WCF服务到使用网站之间移动数据.

在这里进行研究时，尽管有些挠头，但我读了一些精彩的讨论:

• Davide Piras在这篇文章中提出了一些要点，如果我要遵循这种设计，那我d在一个单独的项目中声明POCO的接口.然后，这些将由层(1)和(2)实施.虽然我喜欢使用接口，但似乎我会自己做更多的工作，方法是在(1)和(2)中声明POCO，然后使用诸如AutoMapper之类的方法来回复制它们的数据.

• 此帖子使用的系统中创建了业务对象项目，所有层级都将引用该项目.这似乎比其他解决方案要简单，并且似乎使我想到了一个

的解决方案.

Web site <--> WCF Service (1) <--> Business Layer (2) <--> Data Layer (3)

我的问题是:在解决方案的三层中共享业务对象会产生代码气味吗?还是我上面列出的两种方法只是破解同一个螺母的两种不同方式?

解决方案

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

• 如果您对两者都拥有100％的控制权，则应选择方法#2，因为它可以避免在UI层中WCF代理对象和业务对象之间进行转换.

• 否则，使用方法1会更好，因为其中一个实体有点像黑匣子"，并且可能会受到外部利益相关者的更改.因此，维护内部业务对象集是更安全的.这将需要在您的业务对象和WCF代理对象之间进行转换(通过扩展方法或翻译器框架).

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

• 如果不需要单独的特定于UI的Model，建议将您的业务对象标记为DataContract(在WCF中)，并跨层使用它们.如果要通过网络($.ajax)调用WCF，请不要忘记将实体明确标记为Serializable.

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

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

I've been in the process of re-writing the back-end for a web site and have been moving it towards a three-tiered architecture.

My intention is to structure it so:

Web site <--> WCF Service (1) <--> Business Layer (2) <--> Data Layer (3)

My issue is with the placement of the DTO's within this structure. I'll need to use DTO's to move data between the business layer and the WCF service and from the WCF service to the consuming web site.

During my research on here I've read some excellent discussions though I've been left scratching my head a bit:

• Davide Piras makes some great points in this post and if I were to follow this design then I'd declare interfaces for the POCOs in a separate project. These would then be implemented by tiers (1) and (2). Whilst I like the use of interfaces it does seem like I'd be making more work for myself by declaring POCOs in (1) and (2) and then copying their data back and forth using something like AutoMapper.

• This post uses a system where a business objects project is created which would be referenced by all tiers. This seems to be simplier than the other solution and seems to lead me to a solution that would be

Web site <--> WCF Service (1) <--> Business Layer (2) <--> Data Layer (3)

^               ^                       ^
|               |                       |
[ -- Business Objects Referenced here --]

My question is this: is there a code smell from sharing the business objects across three layers of the solution or are the two methods I've listed above just two different ways of cracking the same nut?

解决方案

Let's think of your UI (website) and service (WCF + BL + DAL) as two distinct entities.

• If you have 100% control over both, you should choose approach #2 since it will avoid translation between WCF proxy objects and your business objects in the UI layer.

• Else, you are better off with approach #1 since one of the entities is kind of a 'black box' and is subject to change by external stakeholders. So, it's safer to maintain an internal set of business objects. This will need translation between your business objects and the WCF proxy objects (through Extension methods or a translator framework).

Now, not exactly sure of your UI layer complexity or its implementation (MVC, WebForms, etc.), so you may or may not need View specific objects (lighter for data-binding, faster to serialize to JSON, etc.), let's call this object as the Model.

• If you don't need a distinct UI specific Model, suggest to mark your business objects as DataContract (in the context of WCF) and use them across layers. Don't forget to explicitly mark entities as Serializable if you are invoking WCF via the web ($.ajax).

• Else, use DataContract in the service and a translator to convert DataContract to Model in the UI layer. A Service Adapter is a good fit here - it sits in the UI layer and is responsible for consuming the WCF service and translating between DataContract and Model. You may use a Service Proxy in the UI layer, which is a wrapper over your WCF service and is consumable over the web.

Lastly, aren't you are missing a reference to the Business Objects in your Data Layer? I believe you will populate your Business Objects from the data-store in the Data Layer itself.

这篇关于将DTO/POCO放在三层项目中的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！