关于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类去获取数据呢?

（编辑：湖南网）

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