这是一个很好的问题.这里有不止一个似是而非的方法;你必须平衡权衡,做出适合你情况的选择.

(1)有些人会认为Document接口应该为实例提供一个自己呈现的方法.这从OO的角度来看是有吸引力的,但是根据您的观点技术,加载您的具体文档类(可能是简单的域模型类),具有JSP,Swing组件或其他内容的知识可能是不切实际的或彻底的丑陋.

(2)有些人会建议在Document上放置一个String getViewName()方法,例如返回可以正确呈现该文档类型的JSP文件的路径.这避免了在一个级别(图书馆依赖/“繁重的”代码)#1的丑恶,但在概念上也提出了同样的问题：您的域模型知道它正在由JSP呈现,并且它知道您的webapp的结构.

(3)尽管有这些观点,如果您的Controller类不知道Universe中存在什么类型的文档,并且每个Document的实例都属于哪个类型,那么会更好.考虑在某种基于文本的文件中设置某种视图映射：.properties或.xml.你使用春天吗？ Spring DI可以帮助您快速指定具体文档类的Map以及渲染它们的JSP / view组件,然后将其传递给Controller类的setter /构造函数.这种方法允许：(1)您的控制器代码与文档类型保持不变,(2)您的域模型保持简单和不可知的视图技术.它是以增量配置为代价的：.properties或.xml.

我会去#3或 – 如果我的预算(及时)在这个问题上工作很小 – 我会(4)只是硬编码一些基本知识的文档类型在我的控制者(正如你所说的现在,现在,为了在下次被迫更新我的控制器时,由于不太优化的OO特性,我们希望在将来切换到#3.事实上,#s 1-3每个都需要更长的时间,比#4更复杂,即使它们更“正确”.与#4同时也是YAGNI Principal的一个点头：没有确定你会遇到#4的负面影响,有意义的是支付前期避免的成本？