数据容器与对象与行为相结合

Question

我正在为工作流层次结构编写一个存储解决方案。

为了简化图片，我有两种类型的对象：Workflow 和 WorkflowStep。

尽管 WorkflowStep 按层次结构位于 Workflow 之下，但 Workflow 不会聚合 WorkflowStep，因为我们将这些对象仅视为数据容器。

因此，这给我留下了以下类：

 public class Workflow : Node {
    public string UID;
    public string parentID;
}

public class WorkflowStep : Node {
    public string UID;
    public string parentID;
}

public class WorkflowEngine {
    public void Store(Workflow wf) {
    }

    public void Store(WorkflowStep wfs) {
    }
}

不在 Workflow 中聚合 WorkflowStep 的原因（即使逻辑上适合）是这些对象纯粹被视为数据容器，它们可能会在以后发生更改，并且我们希望保留存储这些对象与对象本身解耦。

当然，另一种选择是这样做：

 public class Workflow : Node {
    public List<WorkflowStep> steps;
    public string UID;
    public string parentUID;

    public void Store() { }
}

public class WorkflowStep : Node {
    public string UID;
    public string parentID;

    public void Store() { }
}

这两种方法的优点和缺点是什么？有没有任何文献讨论这两种设计？

Answer 1

尽管 Workflow 和 WorkflowStep 都是数据容器，但将它们与分层措施分开并不能解决解耦问题。

将 WorkflowStep 保留在 Workflow 的层次结构上更符合逻辑，并且为了实现解耦，在这种情况下必须引入 IoC。

IoC 的美妙之处在于，更改 WorkflowStep 的定义（它是 Workflow 类中的列表）将是透明的，您只需考虑在 IoC 容器上注册您的类型。

让我为您提供一个使用 Ninject IoC 容器框架的示例。

定义接口并相应地实现数据容器：

public interface IWorkflow {
    string UID { get; set; }    
    string parentID { get; set; }
    IList<IWorkflowStep> Steps { get; set; }
}

public interface IWorkflowStep {
    string UID { get; set; }    
    string parentID { get; set; }
}

 public class Workflow : IWorkflow, Node {

    public string UID { get; set; };
    public string parentID { get; set; };
    public IList<IWorkflowStep> Steps { get; set; }
}

public class WorkflowStep : IWorkflowStep, Node {
    public string UID { get; set; };
    public string parentID { get; set; };
}

现在，Ninject 模块是：

public class WorkflowModule : NinjectModule
{
    #region Overrides of NinjectModule

    public override void Load()
    {
        Bind<IWorkflow>().To<Workflow>();
        Bind<IWorkflowStep>().To<WorkflowStep>();
        Bind<IList>().To<List>();
    }

    #endregion
}

这是将接口与具体类绑定的唯一位置。而在世界其他地方，您只需请求一个已定义接口的实例即可。

要解析您的类型，您需要创建一个 Ninject Kernel，它是一个 IKernel 类型，并且通过加载您定义的 StandardKernel 的具体实现>模块。

这就像，

var kernel = new StandardKernel(new WorkflowModule());

现在，您所要做的就是解决您想要的接口，例如：

IWorkflow workflow = kernel.Get<IWorkflow>();
IWorkflowStep workflowStep = kernel.Get<IWorkflowStep>();

这里的美妙之处在于，您无需担心具体的实现，并且它在您的系统中非常紧密地耦合。它只是您将要处理的接口，剩下的就是您的 IoC 容器实现的担忧。

由于您更担心 WorkflowStep 的实现被更改并且不与 Workflow 耦合。我想，这就是 IoC 发挥作用的地方。

请注意，您可以使用任何IoC容器框架，例如Unity、Spring.NET、StructureMap > 等等。我使用 Ninject 因为我对它很满意。