mvc 一个controler 多个view

刘文涛原创，转载请注明出处。

1.普通意义上的一个controler一个view



2.我要说明的一个controler多个view



3.控制器的作用

视图选择，举个例子：



同样的数据，有时候想显示 表格形式，有时候想显示成图表 (注意：需求不希望2个同时显示)，实现方式有3种：

1）：多个controler,
     每个controler 返回一个view ;controler里面 调用相同的service方法，获得数据(M).
     优点：A:controller中不需要判断该去哪个view(每个需求是不同的入口。)
     缺点：A:代码逻辑重复(controler中), controler泛滥

2）：一个controler一个 view ,
    在view中通过if  else 控制哪些显示，哪些不显示。
    优点：A:controler少,view 少
    缺点：A:view 里面有控制显示不显示的逻辑代码，可读性不好，view层本来是用来做表现的，它做了“额外”的工作。B:不同view 要求必须有相似的界面结构，很难满足差异化需求。比如 一个是左右结构，一个是上中(左右)下 结构。这时候view层里的逻辑简直就是灾难。

3）：一个controler多个view ,
    在controler中通过条件判断该选择不同的view ,每个view 可以从controler 那里拿到相同的数据(M) ,按照自己的风格个性化 呈现。

优点：A：controler 恰当的扮演了 “准备数据” 和 “视图选择” 的 角色。B：视图层没有顾虑只考虑一种情况。C： 不同视图可以天马行空的实现自己的界面布局，彼此之间互不受影响。

缺点：A：view 文件多了，不同view 之间如果有相同的代码，要重复的 写 。

总结 ：

i: 复杂的可扩展要求高的应用，推荐采用  3） 这个方案，对于 3）的 缺点 ，可以采用 include 公用文件，或者自定义标签的形式来解决。
ii: 2)与3)的区别还在于 ：
 
    2)很多时候是 用条件判断 include 不同的代码，保留相同的代码，不同的代码越多，越乱。 拥抱 “相同的”。
    3)相同的代码，要重复的写，相同的越多越觉得重复，修改起来每个view都要改，对于不同的代码这个方案非常欢迎，拥抱“不同的”； 

而问题是如果有 10个view  每3个总能找到相同的，而相同的又不同时适用于10个，这时候，这时候  不但 3）方案有点麻烦，2）方案也麻烦。这时候多采用自定义标签，对界面做细粒度的封装 是不错的选择。