c# - SOA问题: Exposing Entities

Question

我想将 SOA 模式合并到我的 3 层结构中。我在 BLL 和 UI 之间创建了一个服务层(WCF 主机)。我的结构设置现在看起来像这样

UI <> WCF <> BLL <> DAL

   <---[Entities] --->

问题是，我的实体位于单独的 DLL 中(并且它在除 UI 之外的所有层中都可见)现在，我需要公开它，以便我的服务的使用者可以使用它。在本例中，是 UI。我怎么可能做到这一点？

实体.DLL

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

现在，我计划在 WCF 中使用它

服务接口(interface)层

    public class AccountService : IAccountService
    {

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

可以只归属我的实体吗？ (注意，我还使用 DAL 和 BLL 中的实体)

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

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

大家有什么建议吗？

Answer 1

这是适合我们的系统:

您通常应该使用反射(reflect)您期望在客户端需要的数据的数据传输对象。业务层应该定义这些 DTO 及其存储库接口(interface)。数据层应该实现存储库接口(interface)，将数据层实体转换为 DTO。 WCF 层应该只是各种存储库接口(interface)方法的面向外的包装器。

这样，它看起来更像这样:

 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);
}