WCF 和 DI 和业务逻辑层，如何公开 BLL 的所有方法，最佳实践答案

【问题标题】：WCF and DI and Business logic layer, How to expose all methods of BLL, Best practiceWCF 和 DI 和业务逻辑层，如何公开 BLL 的所有方法，最佳实践
【发布时间】：2013-09-25 12:33:45
【问题描述】：

我有

Public Class AuthorBLL : IAuthorBLL
{
    Public Add_Author();
    Public Get_AuthorsList();
}

Public Class BookBLL : IBookBLL
{
    Public Add_Book();
    Public Get_BookList();
}

现在我想在我的 WCF 层中调用我的业务逻辑层方法，并希望向 UI 公开类似的 WCF OperationContracts 方法。

我的 WCF 类如下所示：

Public class WCFService : IWCFService
{
    private IAuthorBLL _authorBLL;
    private IBookBLL _BookBLL;


        public WCFService(IAuthorBLL authorBll, IBookBLL bookBll)
        {
            _authorBLL = authorBll;
         _bookBll = bookBll;    
        }   


    Public WCF_Add_Author (serializable_author author);
    {
        _authorBLL.Add_Author();
}

Public WCF_Get_AuthorsList()
{
    _authorBLL.Get_AuthorList();

}


Public WCF_Add_Book (serializable_book book);
    {
        _bookBll.Add_Book();
}

Public WCF_Get_BookList()
{
    _bookBll.Get_BookList();

}

}

问题：

我的问题是关于 WCF 构造函数，我必须将所有这些业务逻辑层对象作为构造函数参数传递以实现 DI。我怎样才能使它通用，以便将来我有 publisherBLL、VentorBLL、CustomerBLL 等等......我不必在 WCF 构造函数中将它们全部传递？

我知道这是依赖注入的工作方式，但如果我有 50 个 BLL 对象怎么办？我是否必须在 WCF 构造函数中传递它们。有什么办法可以避免吗？任何可以为我提供更好解决方案的设计模式或技术。

我需要保留一个 WCF 服务，它可以公开所有方法，无论是其作者、书籍、出版商、客户、客户还是零售商。一项服务应公开所有 CRUD 方法。

编辑：正如您所说，使用 Ninjet 或 CastleWinsor 进行 IOC，您可以在其中创建容器来定义 DI。但是您仍然必须在 WCF 类的 WCF 构造函数中定义基于构造函数的参数。

我们是否必须如下定义构造函数参数。或者如果 WCF 太大而无法公开这么多方法，那么对于必须为作者、书籍、员工（在商店工作）、出版商、人力资源和工资单模块执行 CRUD 的应用程序来说，什么是解决方案。每个模块都有网页并调用 WCF 服务进行 CRUD。因为我们永远不知道什么时候需要移动到 Mobile 界面，或者有多少其他应用程序将使用相同的方法，所以我们希望通过 WCF 服务公开所有内容。我该怎么办？

private IAuthorBLL _authorBLL;
    private IBookBLL _BookBLL;
    private IClientBll _ClientBll;
    private IPublisherBll _PublisherBll;
    private IHRBll _HRBll;
    private IEmployeeBll _employeeBll;

public WCFService(IAuthorBLL authorBll, IBookBLL bookBll, IClientBll clientBll、IPublisherBll 发布者Bll、IEmployeeBll 员工Bll、IHRBll HRBll) { _authorBLL = 作者Bll； _bookBll = bookBll;
_authorBLL = 作者Bll； _ClientBll = clientBll; _PublisherBLL = 出版商Bll； _HRBll = HrBll; _EmployeeBLL = EmployeeBll;

因为我有很多前端页面来处理员工、作者、客户、书籍、出版商。我该怎么办。

【问题讨论】：

如果您正在创建一个需要 50 个 bll 对象的服务，您应该考虑重构该服务，因为它可能会做很多事情。
谢谢西蒙，但是你会怎么做呢？如果您在 BLL 中有 20 个表和每个表的 4 个 CRUD 方法，那么 20 个网页可以创建、删除和显示这些表数据。您将需要通过 WCF 或您建议的处理方式公开所有这些。数据库很大，有很多网页可以存储和检索静态信息。想想一个巨大的人力资源+工资系统。请问你会怎么做？
我会创建一些较小的服务。这应该会降低复杂性，并且您的服务现在针对较小的功能

标签： c# .net wcf dependency-injection

【解决方案1】：

你自己已经回答得差不多了。如果您使用一些 DI 框架，例如 Unity 或 Ninject，那么您不必费心将 50 参数传递给您的构造函数 - 只需从 DI 框架的工厂检索服务对象，它就会关心关于提供适当的论点。也许您缺少的是您可以在 DI 框架中注册您的服务及其依赖项。

使用 Unity 的简单示例：

在某种初始化整个应用程序的 Bootstrapper 类中：

public void Run()
{
  //...
  SetupContainer();
  //...
  RunWebService();
  //...
}

public void SetupContainer()
{
  //This can also be done using a configuration file

  this.container.RegisterType<IAuthorBLL, AuthorBLLImpl>();
  this.container.RegisterType<IBookBLL, BookBLLImpl>();
  this.container.RegisterType<IOther1BLL, Other1BLLImpl>();
  //...
  this.container.RegisterType<IOther50BLL, Other50BLLImpl>();
}

public void RunWebService()
{
  this.container.RegisterType<IWCFService, WCFService>(
      new ContainerControlledLifetimeManager());

  var serviceSingleton = this.container.Resolve<IWCFService>();

  //... proceed with service setup and run
}

请注意，SetupContainer 通常在不同的模块之间进行拆分。他们每个人都注册了自己的类。

【讨论】：