SOA问题：实体暴露 [英] SOA Question: Exposing Entities

问题描述

我想结合SOA模式在我的3层结构。我创建了BLL和UI之间的服务层（WCF主机）。
我的结构设置，现在看起来是这样的。

UI<> WCF<> BLL<> DAL

 < --- [实体] ---> 
  

现在的问题是，我有我在单独的DLL实体（和它除了在UI）
现在所有层是可见的，我要揭露它，使我的服务的用户可以使用it.In这种情况下，UI。我怎么可能做到呢？

Entities.DLL

 命名空间实体
 {
公共类帐户
 {
公共字符串AcctID {搞定;组; } 
公共字符串AcctName {搞定;组; } 
} 
} 
  

现在而言，我计划使用它在WCF

服务接口层

 公共类的AccountService：IAccountService 
 
  
公共账号是getAccount（字符串AcctID）
 {
 //从DAL BLL通过
} 
取} $ C> 

它是确定，只是我的属性的实体？ （请注意，我还使用在DAL和BLL实体）

 使用System.Runtime.Serialization; 
命名实体
 {
 [DataContract] 
公共类帐户
 {
 [数据成员] 
公共字符串AcctID {搞定;组; } 
 
 [数据成员] 
公共字符串AcctName {搞定;组; } 
} 
} 
  





任何建议家伙？

解决方案

下面是对我们工作的系统：

您应该通常使用数据传输对象反映你期待需要在客户端的数据。业务层应该定义这些DTO的，用自己的资源库接口一起。数据层应实现资源库接口，转换您的数据层实体到DTO的。该WCF层应该仅仅是为您的各种存储库接口方法外向包装

这方式，它看上去更像是这样的：

 
 UI --- \ 
 | BLL  -  DAL 
 WCF --- / 
 [DTO] 
 [库] 
 [实体] 
 

在我的脑海里，我看到了WCF层作为是UI层的一部分，所以我会觉得让他们都知道在业务层中定义对象的所有权利。但是，你可以把它一步，使WCF层负责转换业务对象到的DTO的：

 
 UI  -  -  WCF  -  BLL  -  DAL 
 [DTO的] 
 [库] 
 [Business Objects公司] 
 [实体] 
 

此方式，每一层只知道至多在它每一侧上的单层。该DTO的可注解序列化或什么的，因为他们真的只是用于这一目的。只有在数据访问层是了解你的数据实体的

在响应以您的评论：

如果您的实体都在你的数据访问层定义的，那么他们真的是没有的DTO。它们造型您的数据层，这并不一定直接转化为你的UI所需要的对象。

我建议定义为您的存储库接口的原因是这样就可以使用依赖注入松开你的WCF层和业务层之间的耦合。这也将有助于让你的WCF层的单元测试的，因为你可以创建假的或模拟库实现了模拟特殊情况。

在我推荐的第一款车型，您的WCF方法看起来几乎完全一样你的资料库的方法，因此，典型WCF将基本上只是包装的资源库的方法：

 公共IEnumerable的<任务> GetActiveTasks（）{
返回_taskRepository.GetActiveTasksForUser（_sessionManager.CurrentUser）; 
} 
  

I would like to incorporate SOA pattern in my 3 tier structure. I created a Service layer (WCF Host) between the BLL and the UI. My structure setup is now looks like this

UI <> WCF <> BLL <> DAL

   <---[Entities] --->

The problem is, I have my entities in separate DLL (ANd it was visible in ALL Layers except on the UI) Now, I need to expose it so that the consumer of my service can use it.In this case, the UI. How can I possibly do that?

Entities.DLL

   namespace Entities 
   {
       public class Account
       {
           public string AcctID { get; set; }
           public string AcctName { get; set; }
       }
    }

now, Im planning to use it in WCF

Service Interface Layer

    public class AccountService : IAccountService
    {

         public Account GetAccount(string AcctID)
         { 
             //fetch  from DAL through BLL
          }
     }

Is it ok to just Attribute my Entities? (Note, I'm also using the entities in DAL and BLL)

  using System.Runtime.Serialization;
   namespace Entities 
   {
      [DataContract]
       public class Account
       {
          [DataMember]
           public string AcctID { get; set; }

          [DataMember]
           public string AcctName { get; set; }
       }
    }

Any suggestion guys?

解决方案

Here's the system that works for us:

You should typically use a Data Transfer Object that reflects the data you're expecting to need on the client side. The Business Layer should define these DTOs, along with their repository interfaces. The Data Layer should implement the repository interfaces, converting your data-layer entities into the DTOs. The WCF layer should simply be an outward-facing wrapper for your various repository interface methods.

This way, it looks more like this:

 UI ---\ 
  |     BLL   --   DAL
 WCF---/
    [     DTO    ]
    [Repositories]
                 [Entities]

In my mind, I see the WCF layer as being a part of the UI layer, so I'd feel all right having them both be aware of objects defined in the business layer. However, you could take it one step further, and make the WCF layer be in charge of converting your business objects into DTOs:

 UI   --   WCF   --   BLL   --   DAL
 [    DTOs   ]
         [      Repositories      ]
         [    Business Objects    ]
                              [Entities]

This way, each layer is only aware of at most a single layer on each side of it. The DTOs can be annotated for serialization or whatever, because they really are only intended for that purpose. Only the Data-Access Layer is aware of your Data Entities.

In Response to your comment:

If your entities are defined in your data-access layer, then they really are not DTOs. They are modeling your data layer, which doesn't necessarily translate directly into the objects you need in the UI.

The reason I'm suggesting defining interfaces for your repositories is so that you can use dependency injection to loosen the coupling between your WCF layer and your business layer. This will also serve to make your WCF layer unit-testable, because you can create fake or mock repository implementations that simulate a particular situation.

In the first model I recommended, your WCF methods would look almost exactly like your repository methods, so a typical WCF would basically just "wrap" a repository method:

public IEnumerable<Task> GetActiveTasks() {
    return _taskRepository.GetActiveTasksForUser(_sessionManager.CurrentUser);
}

这篇关于SOA问题：实体暴露的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！