MVC框架可以把应用清晰明了地分为三个部分：Model层–数据层，View层–视图层，Controller–逻辑层，Model层负责整合数据，View层负责页面渲染，Controller层负责实现业务逻辑。
我在这里简单说一下我对MVC框架中的View层的理解。
View层一般包含两个部分：View类和模版文件，View类并不是必需的，采用View类可以整合代码，因为有时候View层也会有一些复杂的逻辑和数据读取的操作，这些操作最好放在类（或者对象）中实现，如果直接在模版文件中实现，会让模版文件很凌乱，不利于代码复用和后期维护。
对于一个Web应用来说，整个应用的风格和页面布局需要保持一致，那么聪明的小伙伴是否联想到了代码复用？假如这个应用一共有200个页面，如何实现“只需在代码中修改一处，就可以修改所有页面的共用部分？”，这是一个非常重要的功能，要不然页面上每一个小改动都需要重复200次，其中难免出错，维护代价高昂。
代码复用的基本思想是“模块化”，每个模块只负责一小部分功能，整个应用的功能就是这些模块的排列和组合，这个思想运用在View层就可以实现上面提到的问题。
那么如何将“模块化”的思想运用在View层的实现上呢？
首先，需要分析web应用页面渲染的特点。一般的，大部分页面共用一个基本布局（基本布局之外没有web内容），在基本布局里面进行划分，比如划分为上下布局，左右布局等，然后再在划分好的小块中再进行布局划分，以此类推，直到完成一个页面的布局。因为一个Web应用的风格和大体布局是一致的，所以上面划分出来的布局中，一部分布局是可以共用的。每一次划分所产生的块都是“模块”，这些“模块”都可以复用，页面与页面之间共用的块，可以通过调用相同的“模块”来实现，需要修改的时候，只需修改“模块”即可，这样就可以达到“只需在代码中修改一处，就可以修改所有页面的共用部分”。
那么如何划分布局呢？（如何把我脑海中对页面布局的划分告诉Web应用？）
我的两种方案：
-
在每个模块中实现对它所包含的子模块的调用。这样，只需要“手动”调取出第一个模块，就可以调取出所有它的子模块，从而完成整个页面的渲染。这个方法的缺点是“环环相扣”并且没法快速查看，如果某个模块渲染不正确，只能一级一级地往上追溯。“环环相扣”导致模块与模块之间的关系非常紧密，有悖于“模块化”的思想。
-
为每一个页面单独设置一个布局的.xml文件，在这个文件中，规定好页面的布局划分，哪个模块包含哪些子模块就一目了然，便于快速定位问题。缺点是.xml文件的解析难度很大，解析.xml文件也非常吃性能，如果页面布局复杂，维护.xml也会非常麻烦。
我比较偏向于第2个方案，第1个方案还有一个非常致命的缺点：页面的渲染过程是逐级展开的，需要在关键节点进行“干预”，使上级模块调取合适的子模块，这也是一个难点，如果需要干预的点太多，就会非常麻烦并且非常凌乱。相比之下，方案2只需要维护.xml文件，只要编写一个完善的解析函数，就可以很好的工作，如果解析.xml文件对性能造成较大影响，可以把解析.xml后所得的布局对象或者数据结构保存在NoSQL数据库中作为缓存（毕竟页面布局不会修改的很频繁），这样可在一定程度上减轻解析.xml文件对性能的影响。
再进一步
有没有发现，上述的第2方案，“为每一个页面单独设置一个布局的.xml文件”会导致众多.xml文件中都会包含大量的重复代码，因为大部分页面的布局有很多位置是相同的或相近似的，所以可以对.xml文件作一些优化，把.xml文件中重复的部分分离出来，单独维护，这样.xml文件的内容就会清爽很多。