我当前的应用程序允许用户通过一组管理屏幕定义自定义 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的知识并创建一个实例。
- 我的问题是双重的:有没有更好的方法来实现我所追求的可组合性?(也许通过使用 IoC 容器或家庭轧制工厂来创建具体的 IFormViewCreator)?
- 我从根本上搞砸了这里的抽象吗?