MVC :
全称： Model – View -Controller
MVC模型的目的是为了将数据模型和视图分离开来，并以控制器作为连接两者的桥梁以实现解耦。
MVC模式在概念上强调 Model, View, Controller 的分离，各个模块也遵循着由 Controller 来处理消息，Model 掌管数据源，View 负责数据显示的职责分离原则，因此在实现上，MVC 模式的 Framework 通常会将 MVC 三个部分分离实现：
- Model 负责数据访问，较现代的 Framework 都会建议使用独立的数据对象 (DTO, POCO, POJO 等) 来替代弱类型的集合对象。数据访问的代码会使用 Data Access 的代码或是 ORM-based Framework，也可以进一步使用 Repository Pattern 与 Unit of Works Pattern 来切割数据源的相依性。
- Controller 负责处理消息，较高级的 Framework 会有一个默认的实现来作为 Controller 的基础，例如 Spring 的 DispatcherServlet 或是 ASP.NET MVC 的 Controller 等，在职责分离原则的基础上，每个 Controller 负责的部分不同，因此会将各个 Controller 切割成不同的文件以利维护。
- View 负责显示数据，这个部分多为前端应用，而 Controller 会有一个机制将处理的结果 (可能是 Model, 集合或是状态等) 交给 View，然后由 View 来决定怎么显示。例如 Spring Framework 使用 JSP 或相应技术，ASP.NET MVC 则使用 Razor 处理数据的显示。
也因为 MVC 模式强调职责分离，所以在发展 MVC 应用时会产生很多文件，在 IDE (集成开发环境) 不够成熟时它会是个问题，但在现代主流 IDE 都能使用类别对象的信息来组织代码编辑的情况下，多文件早已不是问题，而且 MVC 模式会要求开发者进一步思 考应用程序的架构 (Application Architecture)，而非用大杂烩的方式开发应用程序，对于应用程序的生命周期以及后续的可扩充与可维护性而言有相当正面的帮助。另外，MVC 职责分离也带来了一个现代软件工程要求的重要特性：可测试性 (Testability)， MVC-based 的应用程序在良好的职责分离的设计下，各个部分可独立行使单元测试，有利于与企业内的自动化测试、持续集成 (Continuous Integration) 与持续发行 (Continuous Delivery) 流程集成，减少应用程序改版部署所需的时间。
MVC 模式的应用程序的目的就是希望打破以往应用程序使用的大杂烩程序撰写方式，并间接诱使开发人员以更高的架构导向思维来思考应用程序的设计，因此对于一个刚入门的初学者来说，架构导向的思考会有一定的门槛，需要较多的实现与练习才能具备相应的能力，大多数的初学者还是较习惯于大杂烩式的程序撰写，所以可能会对 MVC 模式抱持着排斥或厌恶的心态，然而 MVC (或是其他的Design Patterns) 都是有助于应用程序长远的发展，虽然大杂烩式的程序也可以用来发展长生命周期的应用程序，但是相较于 MVC，大杂烩式的程序在可扩充性和可维护性 (尤其是可测试性) 上会远比 MVC 复杂很多，相反的，MVC 模式的应用程序是在初始开发时期必须先思考并使用软件架构，使得开发时期会需要花较多心力，但是一旦应用程序完成后，可扩充性、可维护性和可测试性反而会因为 MVC 的特性而变得容易。
因此，MVC 模式在已有众多优秀 Framework 的现代，早就己经没有不适合小型应用的问题，小型的应用还是可以由 MVC Framework 的应用来获取 MVC 的优点，同时它也能作为未来小型应用扩充到大型应用时的基础与入门砖。若一开始就想要做大型应用，那么 MVC 模式的职责分离以及要求开发的架构思考会更适合大型应用的开发。
MVC在Android中的实现：
Android中的界面开发就涉及了MVC模式的实现：
在Android中View层一般采用XML文件进行界面的描述
对于Model，大多应用使用本地数据文件或网络获取的数据来封装成依赖于接口的Model
Android中 Activity 通常作为Controller 来绑定 View 和 Model
MVP :
Model – View – Presenter
Presenter : 主要作为沟通View和 Model 的桥梁， 它从Model层查询数据后，返回给View层，是的View和Model之间没有耦合，也将业务员逻辑从View角色上抽离出来。
View : 通常是指Activity、fragment或者某个View控件，它含有一个Presenter对象成员变量。 通常View需要实现一个逻辑接口，将View上的操作转交给Presenter进行实现，最后，Presenter调用View逻辑接口将结果返回给View。
Model : 数据的承载， Model角色主要提供数据的存取功能， Presenter通过Model获取、存取数据。
MVP 模式可以让我从Activity、Fragment等View中抽离出大量的业务逻辑代码，使得他们职责单一，易于维护。
当然，MVP并不是一个标准化的模式，它有很多种实现方式，我们也可以根据自己的需求和自己认为对的方式来修改MVP模式的实现方式。
比如，在Android中，Fragment和Activity 其实是一个粗粒度的View，它们并不仅仅在做单单把View呈现出来，在一些复杂情况下，他们也可以被看做是一个presenter。
对于一个Presenter 有以下的定义：
- 做为一个中间件（中介~就跟卖房子似得，你去买房，中介是不会让你接触房源的房主的）存在于View和Model之间，代码实现上依赖于接口，这个存在是MVP模式的精髓，可以让这个框架解耦，和各个模块职责单一。