不扯复杂理论，从开发需求来说，开发中比较美好的就是把握四个方面：
一 没有重复 没有重复功能的类或函数，一来写着方便，二来维护时不至于在几个相似功能的函数中绕来绕去
二 利于协作 利于团队成员间的配合与协作，拧螺丝的不知道轮胎是橡胶的也能拧
三 易读易改 新人或其它成员需要跨模块来研读代码，应该是清晰易懂，而不是晦涩如天书一般
四 风险易控 有良好的可控性，能够不像一团乱麻那样，避免一堆人不断做着不知道哪天才能做完的东西。
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，并附加或替换一些信息
平时只是有个概念，知道Debug与Release之间生成的程序集运行效率是比较有差异的，只是这次的差异高达60多倍，有点意思。
最近弄公式编辑器，当从数据库中加载了大量的数据后，对这数据处理并解析为Token，然后再按公式的层次自动构成公式网络，此算法在Debug模式下，调试时，发现对数据解析的过程极其缓慢， 花费时间大约有2分钟，平均每0.2~0.4秒处理完成一次解析，后调试发现在Debug模式下主要花费时间都是在创建对象上，在Release下，花费时间不到1秒 - -! 差距还真大。
速度取决于所调试的DLL生成类型，如果使用的类是引用的DLL是经过Release生成的话，速度就不会缓慢，如果是Debug生成的，则速度不会得到改善。
尝试将生成的非通过vs.net点击，而是单独生成运行，Debug模式的仍然速度没有改善多少，而Release即使是在Vs.net的调用模式下，速度也非常理想。