0

我在我的代码中加入了这种模式来实例化业务对象：

// UI or Business level code
public class SomeClass
{
    IOrderFactory orderFactory;

    public SomeClass(IOrderFactory orderFactory)
    {
        this.orderFactory = orderFactory
    }

    public void SomeMethod()
    {
        var newOrder = orderFactory.CreateOrder();
        // Do stuff with new object        
    }
}

// In an interfaces only project
public interface IOrderFactory
{
    Order CreateOrder();
}

// In an implementation project (not seen by most other modules)
public class OrderFactory
{
    public Order CreateOrder()
    {
        return new Order();
    }
}

我们目前使用 Unity 来创建IOrderFactory对象，但我想知道是否可以使用 Unity (IOC) 来生成Order对象本身。

类似的东西unityContainer.Resolve<IOrder>()，每次都制作一个新的吗？

那行得通吗？我们将统一用于我们的服务和功能（即 ViewModels、Helper）类。但我们从未使用它来创建业务对象（如 Customer 或 Order。）

4

3 回答 3

3

在我看来，这一切都取决于构建给定对象（即 WizBang）的实例的复杂程度，以及它的更改频率。

如果 IWizBang 的实现总是 WizBang，或者如果创建 WizBang 实例只涉及调用默认构造函数，那么引入 IOC 容器就大材小用了……您可以轻松地制作工厂方法来为您生成方法。开发人员经常忘记配置复杂性会给刚接触项目的开发人员带来负担，甚至是那些不需要经常添加需要配置的新实体的开发人员。

于 2012-11-09T17:11:12.750 回答
1

新答案

实际上，您将减少模板代码。域类与任何其他类没有什么不同。您可以注册从接口到具体类型的映射，而不是使用工厂类，并在需要时提供 ctor 参数。请参阅http://msdn.microsoft.com/en-us/library/ff648211.aspx

旧答案

通过任何容器解析对象总是比调用虚方法和调用构造函数慢。您不会从 DI 容器中受益的原始性能。

于 2012-11-09T17:04:07.497 回答
1

我会保留 IOrderFactory。DI 容器在为您提供服务方面非常出色，但是当您需要一个实体（特定对象身份很重要的东西）时，使用容器通常会出现问题。

我会这样做有几个原因：

  1. 创建实体往往需要该实体的数据（订单 ID、订单项等），每次创建时这些数据都不同。这对于容器来说变得困难和尴尬。
  2. 为此，您需要将容器实例提供给您的业务逻辑。你真的不希望你的代码直接依赖于容器，除了组合根。根据我的经验，看到大量IUnityContainer依赖项是一个警告信号。

但是，您可以利用容器 - 将 IOrderFactory 作为依赖项，然后将工厂注入容器。然后，您可以将创建订单所需的任何服务注入工厂本身以保留。您也可以将容器注入工厂。

另一种选择是，如果您确实可以创建一个没有超出您配置的特殊参数值的订单，则可以注入一个 Func - 一个工厂函数。这将由容器在运行时生成，并在调用时回调到 container.Resolve。如果您发现需要更多参数或控制，也许您可​​以从那里开始构建 IOrderFactory？

于 2012-11-11T08:30:43.523 回答