9ye.com

来看一个由mvc引申的案例  
   
  a.   problem    
 
MVC给出了一个整个应用的松散的耦合架构。现在来看一下这样一个经常发生的情况。在某一个应用中，用户看到的视图和他所做的操作密切相关。这是一些具有
高度交互性的页面，而这些页面之间含有高度的依赖性。在没有任何模式的时候，这个应用只是一个许多独立的页面的集合，维护和扩展变得异常困难。    

        当一个页面移动后，其他含有这个页面链接的文件，都必须修改。    
        当有一系列页面需要口令保护时，许多配置文件需要修改，或者页面需要包含新的标记。    
        当一个页面需要一个新的表示层时，页面中的标记要被重新安排。    
          当这个系统变得复杂时，这些问题将变得更糟。如果用MVC来解决的话，就变成一个如何管理控制器和视图之间交互的问题。    
  b.   solution    
 
       
前台控制模式可以解决这个问题。这个模式中，所有的请求都被传送到一个对象中。这个主要的对象将处理所有的请求，决定以后显示那一个视图，以及实现必要的
安全需求。对于把视图显示以及其他功能实现集中到一个主要的对象中，将使修改变得很容易，对应用的修改，可以在所有视图中反映出来。    
  c.points    
  *这个模式对于需要在多个含有动态数据的页面之间进行复杂导航的系统来说，是很有效的。    
  *这个模式对于要在所有页面中都包含模板，转换等的应用来说，也是很有效的。    
  *由于视图的选择集中在前端控制器上，因此，视图的导航变得更加容易理解和便于配置。    
  *视图重用和变更会更加容易。    
  *视图之间的复杂交互，使得控制器变得复杂。从而，当应用发展的时候，控制器将变得难以维护。不过，大部分情况下可以用XML映射来解决。    
  *实现应用要求的安全性检验变得很简单。    
  *这个模式不适合小型的，只显示静态内容的应用。

Model-View-Controller   (MVC)   模式基于用户输入将域的建模、显示和操作分为三个独立的类.  
  模型。模型用于管理应用程序域的行为和数据，并响应为获取其状态信息（通常来自视图）而发出的请求，还会响应更改状态的指令（通常来自控制器）。    
  视图。视图用于管理信息的显示。    
  控制器。控制器用于解释用户的鼠标和键盘输入，以通知模型和/或视图进行相应的更改。    
 
请务必注意，视图和控制器都依赖于模型。但是，模型既不依赖于视图，也不依赖于控制器。这是分离的主要优点之一。这样的分离允许模型在独立于可视表示功能
的情况下建立和测试。在许多胖客户端应用程序中，视图与控制器的分离是次要的，实际上，许多用户界面框架将角色实现为一个对象。另一方面，在  
Web   应用程序中，视图（浏览器）与控制器（处理   HTTP   请求的服务器端组件）的分离是很好定义的。    
 
Model-View-Controller  
是一个用于将用户界面逻辑与业务逻辑分离开来的基础设计模式。遗憾的是，此模式的普及导致了许多错误的描述。特别是在不同的上下文中，术语"控制器"已经
用于意指不同的事物。幸运的是，Web   应用程序的出现已经帮助消除了一些不明确性，因为视图与控制器的分离是如此明显。  

其实MVC没错，挺好的，用不用看你的项目的资源、成本、风险等等因素综合考虑  
  我的建议是尽量使用，毕竟他是一个很好的架构模式，对以后的开发也有帮助  
  MVC的内容上面已经说的很清楚了，至于怎么构建这个框架，建议看看微软的示例