15

我当前的应用程序允许用户通过一组管理屏幕定义自定义 Web 表单。它本质上是一个 EAV 类型的应用程序。因此，我不能硬编码 HTML 或 ASP.NET 标记来呈现给定页面。相反，UI 从服务层请求一个 Form 对象的实例，而后者又使用多个 RDMBS 表构造一个。表单包含您希望在这样的上下文中看到的类：Form=> IEnumerable<FormSections>=>IEnumerable<FormFields>

下面是服务层的样子：

public class MyFormService: IFormService{

       public Form OpenForm(int formId){
          //construct and return a concrete implementation of Form 
       }
}

一切都很好（一段时间）。UI 并不知道给定表单中存在哪些部分/字段：它很高兴地将接收到的 Form 对象呈现到功能性 ASP.NET 页面中。

几周后，我收到了业务的新要求：查看不可编辑（即只读）版本的表单时，应将某些字段值合并在一起，并添加其他人为/计算的字段。我说没问题。只需修改我的服务类，使其方法更明确：

public class MyFormService: IFormService{

       public Form  OpenFormForEditing(int formId){
          //construct and return a concrete implementation of Form 
       }

       public Form  OpenFormForViewing(int formId){
          //construct and a concrete implementation of Form  
          //apply additional transformations to the form
       }
}

再次一切正常，平衡已恢复到原力。UI 继续不知道表单中的内容，并且实现了我们的关注点分离。然而，仅仅短短几周后，业务就提出了一个新要求：在某些情况下，我们应该只应用我上面提到的一些表单转换。

在这一点上，感觉就像“显式方法”的方法已经走到了尽头，除非我想以爆炸式的方法结束（OpenFormViewingScenario1、OpenFormViewingScenario2等）。相反，我介绍了另一个级别的间接：

public interface IFormViewCreator{
        void CreateView(Form form);
}

public class MyFormService: IFormService{

       public Form  OpenFormForEditing(int formId){
          //construct and return a concrete implementation of Form 
       }

       public Form  OpenFormForViewing(int formId, IFormViewCreator formViewCreator){
          //construct a concrete implementation of Form  
          //apply transformations to the dynamic field list
           return formViewCreator.CreateView(form);
       }
}

从表面上看，这似乎是可以接受的方法，但有一定的气味。也就是说，一直生活在对OpenFormForViewing的实现细节一无所知的UI中，必须拥有IFormViewCreator的知识并创建一个实例。

  1. 我的问题是双重的：有没有更好的方法来实现我所追求的可组合性？（也许通过使用 IoC 容器或家庭轧制工厂来创建具体的 IFormViewCreator）？
  2. 我从根本上搞砸了这里的抽象吗？
4

2 回答 2

9

据我了解这个问题，您需要先修改表单，然后再将其发送到 UI 层。在我看来，这听起来像是一个装饰器。保留没有 IFormViewCreator 的旧 IFormService 接口。

您现在可以创建一个或多个 Decorating FormService(s) 来实现所需的过滤或修改。

public class MyDecoratingFormService : IFormService
{
    private readonly IFormService formService;

    public MyDecoratingFormService(IFormService formService)
    {
        if(formService == null)
        {
            throw new ArgumentNullException("formService");
        }

        this.formService = formService;
    }

    public Form OpenFormForEditing(int formId)
    {
        var form = this.formService.OpenFormForEditing(formId);
        return this.TransformForm(form);
    }   

    public Form OpenFormForViewing(int formId)
    {
        var form = this.formService.OpenFormForViewing(formId);
        return this.TransformForm(form);
    }

    public Form TransformForm(Form form)
    {
        // Implement transformation/filtering/modification here
    }
}

您现在可以使用一个或多个这样的装饰器来装饰您的原始 IFormService 实现。

IFormService formService = new MyDecoratingFormService(new MyFormService());

您可以根据需要将尽可能多的装饰器（每个都有自己的责任）包裹在彼此周围。

没有明确需要 DI 容器来执行此操作，但它非常适合其他 DI 模式。我一直使用装饰器:)

于 2010-01-28T08:42:03.180 回答
0

除非我想以大量方法结束（OpenFormViewingScenario1、OpenFormViewingScenario2 等）。

您无法消除需求的固有复杂性。通过一种或另一种方式，您将需要检测用例并采取相应措施。

您可以列出所有可能的组合或尝试智能地排除处理 - 如果可能的话。例如，如果由于需求的本质而存在N * M = X可能性，那么详尽地列出X方法确实是不好的。您应该考虑因此必须从和案例X的组合中创建可能的形式。NM

在不知道确切要求的情况下很难说。那么有很多可能的方式来分解这样的组合，例如Decorator、ChainOfResponsability、Filter等。这些都是组合复杂逻辑的方式。

也就是说，一直生活在对OpenFormForViewing的实现细节一无所知的UI中，必须拥有IFormViewCreator的知识并创建一个实例。

演示文稿应分发在其他地方创建的表单，以便与表单创建保持无关。然而，表格需要在某处组装/创建。

在 MVC 中，这样的逻辑进入控制器，它将更新模型/表单并分派到正确的视图/渲染。使用 ASP.NET 也可以做到这一点

于 2010-02-09T10:28:58.560 回答