[移动开发]对于mvc，mvp(结合retrofit，rxjava)，mvvm（结合databinding）的理解结合

m即model：模型和实体，里面放bean类，接口，接口实现类，再细分的话可以再分出contract，里面方接口，model里实现，里面请求网络。

v即view：即UI，存放activity，fragment，自定义view等。

p即presenter：逻辑处理，大量的逻辑处理都放这里面，减轻了activity的职责。调用model里面的网络请求并接收回调，然后去通知view曾渲染界面。

总结：Model提供数据，View负责显示，Controller/Presenter负责逻辑的处理。MVP与MVC有着一个重大的区别：在MVP中View并不直接使用Model，它们之间的通信是通过Presenter (MVC中的Controller)来进行的，所有的交互都发生在Presenter内部，而在MVC中View会直接从Model中读取数据而不是通过 Controller。

在MVC里，View是可以直接访问Model的！从而，View里会包含Model信息，不可避免的还要包括一些业务逻辑。 在MVC模型里，更关注的Model的不变，而同时有多个对Model的不同显示，及View。所以，在MVC模型里，Model不依赖于View，但是View是依赖于Model的。不仅如此，因为有一些业务逻辑在View里实现了，导致要更改View也是比较困难的，至少那些业务逻辑是无法重用的。

在MVP里，Presenter完全把Model和View进行了分离，主要的程序逻辑在Presenter里实现。而且，Presenter与具体的View是没有直接关联的，而是通过定义好的接口进行交互，从而使得在变更View时候可以保持Presenter的不变，即重用！ 不仅如此，我们还可以编写测试用的View，模拟用户的各种操作，从而实现对Presenter的测试--而不需要使用自动化的测试工具。 我们甚至可以在Model和View都没有完成时候，就可以通过编写Mock Object（即实现了Model和View的接口，但没有具体的内容的）来测试Presenter的逻辑。 在MVP里，应用程序的逻辑主要在Presenter来实现，其中的View是很薄的一层。因此就有人提出了Presenter First的设计模式，就是根据User Story来首先设计和开发Presenter。在这个过程中，View是很简单的，能够把信息显示清楚就可以了。在后面，根据需要再随便更改View，而对Presenter没有任何的影响了。 如果要实现的UI比较复杂，而且相关的显示逻辑还跟Model有关系，就可以在View和Presenter之间放置一个Adapter。由这个 Adapter来访问Model和View，避免两者之间的关联。而同时，因为Adapter实现了View的接口，从而可以保证与Presenter之间接口的不变。这样就可以保证View和Presenter之间接口的简洁，又不失去UI的灵活性。 在MVP模式里，View只应该有简单的Set/Get的方法，用户输入和设置界面显示的内容，除此就不应该有更多的内容，绝不容许直接访问Model--这就是与MVC很大的不同之处。

优点：

1、模型与视图完全分离，我们可以修改视图而不影响模型

2、可以更高效地使用模型，因为所有的交互都发生在一个地方——Presenter内部

3、我们可以将一个Presenter用于多个视图，而不需要改变Presenter的逻辑。这个特性非常的有用，因为视图的变化总是比模型的变化频繁。

4、如果我们把逻辑放在Presenter中，那么我们就可以脱离用户接口来测试这些逻辑（单元测试）

缺点：

由于对视图的渲染放在了Presenter中，所以视图和Presenter的交互会过于频繁。还有一点需要明白，如果Presenter过多地渲染了视图，往往会使得它与特定的视图的联系过于紧密。一旦视图需要变更，那么Presenter也需要变更了。比如说，原本用来呈现Html的Presenter需要用于呈现Pdf，那么Presenter很有可能也需要变更。

MVVM模式分为Model，View，ViewModel 三个部分

(1).Model:数据层，包含数据实体和对数据实体的操作
(2).View:界面层，对应于Activity，XML,View，负责数据显示以及用户交互。
(3).ViewModel：关联层，将Model和View进行绑定，Model或者View更改时，实时刷新对方。

优点

1.View只做和UI相关的工作，不涉及任何业务逻辑，不涉及操作数据，不处理数据。UI和数据严格的分开
2.ViewModel只做和业务逻辑相关的工作，不涉及任何和UI相关的操作，不持有控件引用，不更新UI。

1),使得M,V,VM的解耦更加彻底，在mvp模式中，p需要持有V的引用，才能去刷新UI，在MVVM模式中，View和Model使用databingding进行双向绑定，一方改变会直接通知另外一方，使得viewModel能专注于业务逻辑的处理，而不需要去关心UI刷新。
2),不会像MVC一样导致Activity中代码量巨大，也不会像MVP一样出现大量的View接口(Presente与View是通过接口进行交互的)。项目结构更加低耦合。

Databinding和MVVM的关系

MVVM是一种架构模式，DataBinding是一个实现数据和UI绑定的框架，是实现MVVM模式的工具。

使用databinding在xml中可以直接设置网络请求的内容

retrofit

使用：定义一个接口，一般都叫xxxService，里面可以设置接口名称和参数以及header和请求方式（例如get和post，put等）例如

@Headers({"Content-Type: application/json"})//多个header用逗号分割
@GET("app/version")
Observable<BaseResponse<xxxBean>> getVersions();//括号里可加参数@Query("aa") String aa

如果是post请求就加body?@Body RequestBody body

在contract中调用上一级

@Override
public Observable<BaseResponse<xxxBean>> getVersions() {

RequestBody body = FormBody.create(MediaType.parse("application/json;charset=utf-8"), JsonUtil.gsonString(loginPostBean));

    return mRepositoryManager.obtainRetrofitService(xxxService.class)
            .getVersions();//有参数传参数，没有参数就不传
}

在presenter中调用上一级

rxjava：

?
Retrofit retrofit = new Retrofit.Builder()
? ? ? ? .baseUrl("https://api.douban.com/v2/")
? ? ? ? .addConverterFactory(GsonConverterFactory.create(new GsonBuilder().create()))
? ? ? ? .addCallAdapterFactory(RxJavaCallAdapterFactory.create())//支持RxJava
? ? ? ? .build();

@GET("book/search")

Observable<Book> getSearchBook(@Query("q") String name,@Query("tag") String tag, @Query("start") int start,@Query("count") int count);//结合了rxjava原来的call变成了先在的Observable

就可以在presenter中创建观察者去观察这只接口了

等有时间再写。。。先去吃饭