MVC和MVP

## 架构

    *
b/s架构:

    *
mvc:设计思想                  mvc与23种设计模式没有任何关系

    *
        * M:model javaBean domain
        * V:view xml view adapter
        * C:Ctroller Activity Fragment

    * mvp:设计思想  （了解）

    *
        * M:model
        * V:View
        * P:Presenter

    *
四层架构:自我总结

    *
        * 数据提供层-->dataProvider:提供数据
        *

        * 数据持久层-->data persistent-->sqlite ,sp,file
        * 业务逻辑层-->servcie logic     进公司看不明白代码就在这一层次
        * ui展现层


去公司拿到代码如何看？
1 数据提供层
   ①网络请求怎么做的（okhttp，volley，httputils）
   ②json如何解析的（Gson  Fastjson）
   ③图片加载（volley，imageloader）
2 数据持久层
①sqlite数据库或者本地sp，file缓存

3 ui展现层
①具体页面分析

4 业务逻辑层：简单业务逻辑
①登录，注册为主


    *

    * 数据存储到哪里？     Db   服务器数据返回的形式是啥？jsonString   

DB文件如何变成JsonString？？胡扯

Web管理系统是运行在浏览器的管理系统
web程序无法直接操作文件，所以需要web管理系统Servier来操作数据库
笔记JAVA  --  jdbc   操作DB数据库


MVC
MVC全名是Model View Controller ，是模型 (model)－视图(view) －控制器 (controller)的缩写，一种软件设计典范，用一种业务逻辑、数据、界面显示分离的方法组织代码，将业务逻辑聚集到一个部件里面，在改进和个性化定制界面及用户交互的同时，不需要重新编写业务逻辑。 MVC被独特的发展起来用于映射传统的输入、处理和输出功能在一个逻辑的图形化用户界面的结构中。
    （控制器Controller）- 负责转发请求，对请求进行处理。
    （视图View） - 界面设计人员进行图形界面设计。
    （模型Model） - 程序员编写程序应有的功能（实现算法等等）、数据库专家进行数据管理和数据库设计(可以实现具体的功能)。

模型（Model） “数据模型”（Model）用于封装与应用程序的业务逻辑相关的数据以及对数据的处理方法。“模型”有对数据直接访问的权力，例如对数据库的访问。
“模型”不依赖“视图”和“控制器”，也就是说，模型不关心它会被如何显示或是如何被操作。但是模型中数据的变化一般会通过一种刷新机制被公布。
为了实现这种机制，那些用于监视此模型的视图必须事先在此模型上注册，从而，视图可以了解在数据模型上发生的改变。（比较：观察者模式）

视图（View） 视图层能够实现数据有目的的显示。在视图中一般没有程序上的逻辑。为了实现视图上的刷新功能，视图需要访问它监视的数据模型（Model），因此应该事先在被它监视的数据那里注册。

控制器（Controller） 控制器起到不同层面间的组织作用，用于控制应用程序的流程。它处理事件并作出响应。“事件”包括用户的行为和数据模型上的改变。

MVP
MVP 是从经典的模式MVC演变而来，它们的基本思想有相通的地方：
Controller(控制器)/Presenter(主持人、协调者)负责逻辑的处理，Model提供    数据，View负责显示

作为一种新的模式，MVP与MVC有着一个重大的区别：在MVP中View并不直接使用Model，它们之间的通信是通过Presenter (MVC中的Controller)来进行的，所有的交互都发生在Presenter内部，而在MVC中View会从直接Model中读取数据而不是通过 Controller。

在MVC里，View是可以直接访问Model的，从而，View里会包含Model信息，不可避免的还要包括一些业务逻辑。 所以，在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很大的不同之处。


MVP的优点：
1、模型与视图完全分离，我们可以修改视图而不影响模型
2、可以更高效地使用模型，因为所有的交互都发生在一个地方——Presenter内部
3、我们可以将一个Presenter用于多个视图，而不需要改变Presenter的逻辑。这个特性非常的有用，因为视图的变化总是比模型的变化频繁。
4、如果我们把逻辑放在Presenter中，那么我们就可以脱离用户接口来测试这些逻辑（单元测试）

MVP代码举例：
模拟一个需求：首先我们要进入一个 Splash界面， Splash界面中，有一个
ProgressBar控件和TextView控件，我们判断它是否有网络连接，如果有的话就隐藏  ProgressBar和TextView,跳转到MainActivity如果没有网络的话则显示ProgressBar和TextView，TextView则提示用户No internet。就这么简单的一个需求，我们看看如何用MVP模式做这个需求：


M层接口：
public interface IConnectionStatus {
  boolean isOnline();
}

M层实现：
import com.manning.androidhacks.hack020.presenter.model.IConnectionStatus;
public class ConnectionStatus implements IConnectionStatus {
  @Override
  public boolean isOnline() {
       return true; // 这里应该检测是否联网，此处先简单的return true代替
  }
}
V层接口：
public interface ISplashView {
  void showProgress();
  void hideProgress();
  void showNoInetErrorMsg();
  void moveToMainView();
}

V层实现：

public class SplashActivity extends Activity implements ISplashView {

  private TextView mTextView;
  private ProgressBar mProgressBar;
  private SplashPresenter mPresenter ; // P层

  @Override
  public void onCreate(Bundle savedInstanceState) {
    super.onCreate(savedInstanceState);
    setContentView(R.layout.splash);

    mPresenter = new SplashPresenter(this);  // 设置ISplashView 给P层

    mTextView = (TextView) findViewById(R.id.splash_text);
    mProgressBar = (ProgressBar) findViewById(R.id.splash_progress_bar);
  }

  @Override
  protected void onResume() {
    super.onResume();
    mPresenter.didFinishLoading();  // 通过P层间接调用M层
  }

  public void showProgress() {
    mProgressBar.setVisibility(View.VISIBLE);
  }

  public void hideProgress() {
    mProgressBar.setVisibility(View.INVISIBLE);
  }

  public void showNoInetErrorMsg() {
    mTextView.setText("No internet");
  }

  @Override
  public void moveToMainView() {
    startActivity(new Intent(this, MainActivity.class));
  }
}

P层实现：

public class SplashPresenter {
    private IConnectionStatus  connectionStatus;
    private ISplashView splashView;

    public SplashPresenter(ISplashView  splashView){
        this.splashView = splashView;
        connectionStatus = new ConnectionStatus (this);
    }

    public void didFinishLoading() {
        if (connectionStatus.isOnline) {
            splashView.hideProgress(); // 有网，则隐藏ProgressBar
            splashView.moveToMainView(); // 跳转到主页面
        } else {
            splashView.showProgress(); // 没网，展示Progressbar
            splashView.showNoInetErrorMsg(); // 设置错误信息
        }
    }
}

android鼓励弱耦合和组件的重用，在android中MVC的具体体现如下：

1.    视图层（view）：一般采用xml文件进行界面的描述，使用的时候可以非常方便的引入，将展示给用户看的布局界面从代码中分离出去。

2.    控制层（controller）：android的控制层的重任通常落在了众多的Activity的肩上，这句话也就暗含了不要在Activity中写代码，要通过Activity交割到model业务逻辑层处理，这样做的另外一个原因是android中的Activity的响应时间是5s，如果耗时的操作放在这里，程序就很容易导致ANR异常。

3.    模型层（model）：对数据库的操作、对网络等的操作都应该在model里面处理，所有的业务逻辑相关都应放到该层中。业务逻辑执行结束后，model层将执行结果传递给controller，由controller将结果反馈到view层上，从而反馈给用户。