关于MVC/MVP/MVVM的一些错误认识

我们做业务模块开发时，会经常定义一些数据结构类，比如个人资料可能会对应一个UserProfile类，一条订单数据可能会对应一个Order类，这些类没有任何逻辑，只有一些简单的getter、setter方法。有些人会认为像UserProfile或者Order这样的数据结构类就是Model。

我们已经强调了，Model层包含了业务数据以及对业务数据的操作。像UserProfile或者Order这样的数据结构类的实例甚至都不能称之为对象，可以看一下Uncle Bob的Classes vs. Data Structures这篇文章，对象是有行为的，一个数据结构实例没有行为，连对象都称不上，怎么能代表Model层呢!

静态的业务数据不能代表Model层，业务数据以及针对业务数据的操作共同构成了Model层，这也就是业务逻辑。再举个例子说一下吧，假设你在做一个叫“掘铁”的app，这个app现在只有一个页面，用来展示推荐的博客列表。OK，我们如果用MVP的形式该怎么写呢?我们就先不管和Model层完全没有交互的View了，Presenter层除了处理表现层逻辑外，还要向Model层发出业务指令，注意，Presenter并不处理业务逻辑，真正的业务逻辑还是由Model层完成。示例代码大概是下面这样：

public class RecommendBlogFeedPresenter { 
    private RecommendBlogFeedView view; 
    private BlogMode model; 
    public void onStart() { 
        view.showLoadWait(); 
        model.loadRecommendBlogs(new LoadCallback<>() { 
            @Override 
            public void onLoaded(List<Blog> blogs) { 
                view.showBlogs(blogs); 
            } 
        }) 
    } 
} 
 
 
public interface BlogModel { 
    void loadRecommendBlogs(LoadCallback<List<Blog>> callback); 
} 
public class BlogModelImpl implements BlogModel { 
    private BlogFeedRepository repo; 
    @Override 
    public void loadRecommendBlogs(LoadCallback<List<Blog>> callback) { 
        // BlogFeedRepository.fetch()很可能是耗时操作，所以实际写的时候会在非主线程执行，这里只是示例 
        callback.onLoaded(repo.fetch("recommend")); 
    } 
} 
public interface BlogFeedRepository { 
    List<Blog> fetch(String tag); 
} 

什么?你这个BlogModelImpl里就这一行代码，你跟我说这是业务逻辑?大家冷静一下，把手里的板砖、砍刀、狼牙棒先放下来。BlogModelImpl类里面的逻辑虽然简单，但是它的确是业务逻辑，也正是因为业务逻辑比较简单，所以BlogModelImpl类才会很简洁。

再从Presenter的角度看一下，为什么loadRecommendBlogs()属于业务逻辑。博客这个概念毫无疑问属于业务概念，根据前面的解释应该可以判断出来“获取推荐的博客列表”不属于表现层逻辑，那么这个逻辑的实现就不是Presenter需要关心的，那就应该是Model层的职责，既然是Model层的那就应该是业务逻辑了;再者，既然博客是业务概念，那么Blog就是业务数据的数据结构，loadRecommendBlogs()涉及到对业务数据Blog的创建及组装等操作，所以也应该是业务逻辑。

看到这里，可能有些人会产生一些误解：所谓的业务逻辑处理就是网络请求、数据库查询等数据获取逻辑，即Model层就是负责数据获取的，这也是我要说的第三个错误观点。稍等，我先写个标题⬇

错误三：Model层就是负责数据获取的

产生这种错误认识的，说白了还是没有搞懂业务逻辑。当然了业务逻辑本身就是很抽象的概念，难理解，也很难区分，我也不敢往细了去说，因为说多了怕被你们发现其实我也是在裸泳。

业务逻辑层并不负责数据的获取，数据的获取职责还要在Model层的更下层，这也是为什么我要把的BlogModel的实现逻辑写得如此简单，因为数据获取的职责全部交给了BlogFeedRepository类，Model层只处理业务逻辑。BlogFeedRepository是博客列表的仓储类，BlogModel通过BlogFeedRepository的fetch()方法获取标签为recommend的博客列表，也就是推荐的博客列表。BlogModel不关心BlogFeedRepository是如何获取对应博客数据的，它可以是从通过网络请求获取的，也可以是从本地数据库中获取的，数据源有任何改变也不应该影响到BlogModel中的业务逻辑。

那么既然BlogModel中的业务逻辑如此简单，为什么要强行增加这么一个Model层，而不是让Presenter直接使用BlogFeedRepository类去获取数据呢?

（编辑：衡阳站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!