本文编译自J2EE的相关文档。
MVC（Model-View-Controller）应用程序结构被用来分析分布式应用程序的特征。这种抽象结构能有助于将应用程序分割成若干逻辑部件，使程序设计变得更加容易。
MVC结构提供了一种按功能对各种对象进行分割的方法（这些对象是用来维护和表现数据的），其目的是为了将各对象间的耦合程度减至最小。MVC结构本来是为了将传统的输入（input）、处理（processing）、输出（output）任务运用到图形化用户交互模型中而设计的。但是，将这些概念运用于基于Web的企业级多层应用领域也是很适合的。
在MVC结构中，模型（Model）代表应用程序的数据（data）和用于控制访问和修改这些数据的业务规则（business rule）。通常模型被用来作为对现实世界中一个处理过程的软件近似，当定义一个模型时，可以采用一般的简单的建模技术。
当模型发生改变时，它会通知视（View），并且为视提供查询模型相关状态的能力。同时，它也为控制器（Controller）提供访问封装在模型内部的应用程序功能的能力。
一个视（View）用来组织模型的内容。它从模型那里获得数据并指定这些数据如何表现。当模型变化时，视负责维持数据表现的一致性。视同时将用户要求告知控制器（Controller）。
控制器（Controller）定义了应用程序的行为；它负责对来自视的用户要求进行解释，并把这些要求映射成相应的行为，这些行为由模型负责实现。在独立运行的GUI客户端，用户要求可能是一些鼠标单击或是菜单选择操作。在一个Web应用程序中，它们的表现形式可能是一些来自客户端的GET或POST的HTTP请求。模型所实现的行为包括处理业务和修改模型的状态。根据用户要求和模型行为的结果，控制器选择一个视作为对用户请求的应答。通常一组相关功能集对应一个控制器。下图描述了一个MVC应用程序中模型、视、控制器三部分的关系： 
图中实线表示高耦合的依赖关系，虚线表示低耦合的消息关系。业务模块是不依赖用户界面的，这样就隔离了用户界面的变更对业务程序的影响。用户界面负责收集用户的输入，显示用户需要的数据；控制器负责将用户的请求调用到实际的业务程序，也将业务程序处理的结果回送给用户界面；业务程序具体处理业务操作。同时业务模块可能主动发送消息到用户界面，通知界面显示数据。
在具体的环境下，这些因素可能发生一些变化。比如，在web开发中，由于web应用程序的性质，用户界面是在浏览器上运行的，而界面的控制和业务模块在浏览器上运行，所以在web应用中通常采用这种典型的MVC模式。并且在Web应用中，不存在服务器主动向客户端“推”数据，因此从Model到View之间的虚线也是不存在的。在windows窗体程序中，控制器和界面经常是合并在一起的，比如MFC框架中使用的Document－View模式，其中的Document对应MVC中的Model，负责保存业务数据，处理业务逻辑，View相当于MVC中的View＋Controller，负责用户界面的显示、用户输入的收集和画面的跳转控制。