不扯复杂理论，从开发需求来说，开发中比较美好的就是把握四个方面：
一 没有重复 没有重复功能的类或函数，一来写着方便，二来维护时不至于在几个相似功能的函数中绕来绕去
二 利于协作 利于团队成员间的配合与协作，拧螺丝的不知道轮胎是橡胶的也能拧
三 易读易改 新人或其它成员需要跨模块来研读代码，应该是清晰易懂，而不是晦涩如天书一般
四 风险易控 有良好的可控性，能够不像一团乱麻那样，避免一堆人不断做着不知道哪天才能做完的东西。
MVC中View可以成一个一个的小片段，并且它由Controller来进行控制应该显示谁，这里的Controller负担着两个任务，一个是从数据层提取数据转换成所需求的数据，然后就是把此数据推入到View中进行显示。每个View中几乎只需要描述自己要显示什么，需要些什么来显示即可。
这样处理的好处就是，Coder与Desinger可以分离协作，美工只用考虑划分一块块的View,然后必要时进行组合与变换。
从这个角度上来说，View内部也不仅仅是简单的HTML，比如有可能会涉及到换肤或是显示变化，这可以考虑用多个VIEW平级实现，也可以考虑在View内进行分层，然后用统一的View作为视角统一处理，决定哪个视角就是Controller的问题了。
控件组装方式实现MVC有点困难的地方在于，ASP.NET的中的ascx组合常给人以不爽的感觉， 同时ASP.NET自身的标签描述写起来又是很麻烦的，在使用nv模板的情况下，一个变量描述不过$var就OK了，打击键盘实际上会让人感觉很舒服，另外View一般是比较简短的，也不会涉及太多的逻辑，在View中，采用code beside的方式，其实最舒服的，因为它通常并不会有太困难的维护问题。
控制层的最大作用实际上就是决定要干什么。比如一个Url里描述是订单请求，那么就转到订单显示页面，这里并且还进一步处理，是请求的订单第几步，应该组合哪些View来显示，这里应该只考虑转入哪个View就够了，通知View层应该显示哪个对应的View，换句话说，Cotroller更应该是一个转发层，它就是中心逻辑处理，根据请求及对请求的分析，决定显示什么。说白了，它就是处理request与Response的。
说说模型层，数据访问弄在Model里问题并不大，只是对于Modal这里，它并不是单纯的Entity，而是Modal，从概念上应该是有区分的它与数据访问提取出来的来数据还有一个转化后的关系。原始的数据访问提取出来数据，直接赋值成为Entity似乎没有大问题，但那只是原始数据，如果有一个树形结构呢？这个就是模型层的作用，在提取数据后，直接组装出树的模型，然后作为View的供给者,View就可以轻易的显示出树来了。
一般情况下Model的职责
1 提取数据，并构建相应的实体类
2 根据View所需要，提供相应的数据模型
一般情况下View的职责：分主View与子View
1 主View负责显示组装后的View，Controller中决定要显示的的就是主View
2 子View负责与Modal对应成一个个View，以便用于主View的组装一般情况下Contoller的职责：
1 处理request，通常一定需要分析request相应的参数，以便决定显示哪个主View
2 处理reponse, 通常偶尔需要分析response，并附加或替换一些信息
