[译]MVC or MVP Pattern – Whats the difference?

最近在研究MVC和MVP模式，看了很多博文，其中就有这么一篇感觉写的不错的，我 上一篇博文其实就是参考这篇的观点的。
原文地址
出于学习研究以及锻炼一下英语的心态，翻译了这篇文章，有些地方翻译的不太到位，欢迎指出我的问题。
看完这篇再看下MVP框架模式，应该更好

• Over the years I have mentored many developers on using design patterns and best practices. One question that keeps coming up over and over again is: What are the differences between the Model View Controller (MVC) and Model View Presenter (MVP) patterns? Surprisingly the answer is more complex than what you would suspect. Part of reasons I think many developers shy away from using either pattern is the confusion over the differences.

译：
多年来我有辅导很多开发人员去使用设计模式和最佳的实践。一遍又一遍地不断涌现的一个问题是:MVC 和 MVP的区别究竟在哪里?让你惊奇的是答案可能比你想象的更复杂。我认为许多开发人员回避这个问题的其中之一的原因其实是对使用这两种模式区别的混乱。

• Before we dig into the differences let’s examine how the patterns work and the key benefits to using either one. Both (MVC & MVP) patterns have been use for several years and address a key OO principal namely separation of concerns between the UI and the business layers. There are a number of frameworks is use today that based on these patterns including: JAVA Struts, ROR, Microsoft Smart Client Software Factory (CAB), Microsoft Web Client Software Factory, and the recently announced ASP.Net MVC framework.

译：
之前我们深入研究MVC&MVP的区别，以发现其工作原理和使用它们的主要优点。(MVC & MVP)模式已经使用了好几年,解决一个关键面向对象的问题主要就是关注分离UI和业务层。现在有许多框架是基于这些模式拓展的，包括:JAVA Struts, ROR, Microsoft Smart Client Software Factory (CAB), Microsoft Web Client Software Factory,和最近宣布的ASP.Net MVC framework.

Model View Controller (MVC) Pattern

• The MVC pattern is a UI presentation pattern that focuses on separating the UI (View) from its business layer (Model). The pattern separates responsibilities across three components: the view is responsible for rending UI elements, the controller is responsible for responding to UI actions, and the model is responsible for business behaviors and state management. In most implementation all three components can directly interact with each other and in some implementations the controller is responsible for determining which view to display (Front Controller Pattern).

译：
MVC模式是一种UI表示模式,着重于从业务层(Model)分离UI(视图)。模式分离旨在三个部分:视图负责渲染UI元素,控制器负责响应用户界面操作,和模型负责业务行为和状态管理。在大多数实现中这三个组件可以直接相互作用和在一些实现中控制器负是责决定哪些视图显示(前端控制器模式),

Model View Presenter (MVP) Pattern

• The MVP pattern is a UI presentation pattern based on the concepts of the MVC pattern. The pattern separates responsibilities across four components: the view is responsible for rending UI elements, the view interface is used to loosely couple the presenter from its view, the presenter is responsible for interacting between the view/model, and the model is responsible for business behaviors and state management. In some implementations the presenter interacts with a service (controller) layer to retrieve/persist the model. The view interface and service layer are commonly used to make writing unit tests for the presenter and the model easier.

译：
MVP模式是基于MVC模式的概念的一种UI表示模式。模式把责任分离为四个组成部分:视图负责渲染UI元素,视图接口用于把presenter从View中解耦,presenter负责View和Model之间的交互,以及Model负责业务行为和状态管理。在一些实现中，Presenter与服务(控制器)层进行交互检索/持久化Model。View 接口和服务层一般用于让Prensenter和Model编写单元测试更容易。

Key Benefits

• Before using any pattern a developers needs to consider the pros and cons of using it. There are a number of key benefits to using either the MVC or MVP pattern (See list below). But, there also a few draw backs to consider. The biggest drawbacks are additional complexity and learning curve. While the patterns may not be appropriate for simple solutions; advance solutions can greatly benefit from using the pattern. I’m my experience a have seen a few solutions eliminate a large amount of complexity but being re-factored to use either pattern.

译：
在使用任何模式之前，开发人员需要考虑使用它的优点和缺点。使用MVC或MVP模式有很多好处(请参阅下面的列表)。但是,也有一些缺点需要考虑。最大的缺点是复杂性的增加以及学习的难度。虽然这些模式可能不适合做简单的解决方案,但好的解决方案可以大大受益于使用模式。我的经验里已经看到几个解决方案消除了大量的复杂但重构使用模式。

• Loose coupling – The presenter/controller are an intermediary between the UI code and the model. This allows the view and the model to evolve independently of each other.
• Clear separation of concerns/responsibility
  o UI (Form or Page) – Responsible for rending UI elements
  o Presenter/controller – Responsible for reacting to UI events and interacts with the model
  o Model – Responsible for business behaviors and state management
• Test Driven – By isolating each major component (UI, Presenter/controller, and model) it is easier to write unit tests. This is especially true when using the MVP pattern which only interacts with the view using an interface.
• Code Reuse – By using a separation of concerns/responsible design approach you will increase code reuse. This is especially true when using a full blown domain model and keeping all the business/state management logic where it belongs.
• Hide Data Access – Using these patterns forces you to put the data access code where it belongs in a data access layer. There a number of other patterns that typical works with the MVP/MVC pattern for data access. Two of the most common ones are repository and unit of work. (See Martin Fowler – Patterns of Enterprise Application Architecture for more details)
• Flexibility/Adaptable – By isolating most of your code into the presenter/controller and model components your code base is more adaptable to change. For example consider how much UI and data access technologies have changed over the years and the number of choices we have available today. A properly design solution using MVC or MVP can support multi UI and data access technologies at the same time.

译：

• 解耦 -presenter/controller 是视图（UI、View）代码以及模型（Model）之间的媒介。这样使得视图和模型相互独立了。
• 关注点和职责的分离
  
  • View —负责渲染UI页面元素
  • Presenter —负责对UI事件和模型（Model）进行交互
  • Model —负责业务行为和状态管理
• 测试驱动 -通过主要组件的解耦，更容易编写单元测试。MVP模式和View交互只通过接口，所以尤其如此。
• 代码重用 -通过使用这种分离 关注点和职责 的设计方式将让你增加代码的重用率。当用一个完整的域Model和包含着所有的业务逻辑以及状态的代码块，是非常容易重用的。（这句话翻译的感觉不到位，真心不好意思…）
• 数据隐藏 -用这些模式将会迫使你使用代码来访问数据，就是所谓的数据访问层。有许多模式和典型的MVP/MVC模式使用来访问数据。
• 灵活性、适配性 -通过抽出你的代码放进Presenter和Model模块，你的代码库将会更加容易适应改变。例如多年来有多少用户界面和数据访问技术改变以及我们今天选择使用的技术的数量。一个正确的设计方法是使用MVC/MVP来使得我们的系统在同一时间支持多用户界面以及数据访问。

Key Differences

So what really are the differences between the MVC and MVP pattern. Actually there are not a whole lot of differences between them. Both patterns focus on separating responsibility across multi components and promote loosely coupling the UI (View) from the business layer (Model). The major differences are how the pattern is implemented and in some advanced scenarios you need both presenters and controllers.

Here are the key differences between the patterns:

• MVP Pattern

  • View is more loosely coupled to the model. The presenter is responsible for binding the model to the view.
  • Easier to unit test because interaction with the view is through an interface
  • Usually view to presenter map one to one. Complex views may have multi presenters.

• MVC Pattern

  • Controller are based on behaviors and can be shared across views
  • Can be responsible for determining which view to display (Front Controller Pattern)

Hopefully you found this post interesting and it helped clarify the differences between the MVC and MVP pattern. If not, do not be discouraged patterns are powerful tools that can be hard to use sometimes. One thing to remember is that a pattern is a blue print and not an out of the box solutions. Developers should use them as a guide and modify the implementation according to their problem domain.

译：
所以什么才是MVC/MVP模式的真正的区别，事实上这两者没有一个很完全区别。两个模式都迫使程序设计通过多个模块分离职责和促使View层和具体的业务逻辑层（Model）解耦.最主要的区别是模式是怎么实现的，以及在特殊高级的场景里是怎么使用Presenters 和 controllers的。

下面是两者模式关键：

MVP

• View和Model更加解耦. Presenter是View和Model直接的纽带。
• 更容易单元测试，因为通过接口和View层交互
• 经常View和Presenter是一一对应的. 复杂的View有时候对应多个Presenter.

MVC

• Controller是基于行为的，并且能够共享多个View
• 可以决定哪个View显示

希望你觉得这篇博文是有趣的，也许能帮你看清MVC和MVP模式之间的差异。如果没有，也不要认为这些模式是难以实现的。要记住一个事情，一个模式就是一个蓝图，并且不是一个开箱即用的解决方案。开发人员应该根据自己的问题使用它们作为指导和修改现有的实现方案。