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

当然是有原因的!假设我们刚才介绍的“掘铁”app，在仅有一个博客列表页面的情况下，依然吸引了很多用户去使用，产品经理此时决定尝试探索变现手段，首先是在博客推荐列表中添加广告数据。再假设，由于广告数据和博客数据分属不同的后端团队，两边数据尚未整合打通，暂时由客户端负责把广告数据添加到博客列表中。这个时候，BlogModel终于凸显了它存在的必要性。表现层不负责广告数据的获取与整合，BlogFeedRepository也不能负责广告数据的获取与整合。广告数据的整合是业务逻辑，由BlogModel负责，广告数据的获取由专门的数据仓储类负责。示例代码如下：

public class BlogModelImpl implements BlogModel { 
    private BlogFeedRepository blogRepo; 
    private AdRepository adRepo; 
    private BlogAdComposeStrategy composeStrategy; 
    private AdBlogTransform transform; 
    @Override 
    public void loadRecommendBlogs(LoadCallback<List<Blog>> callback) { 
        List<BlogAd> ads = adRepo.fetch("recommend"); 
        List<Blog> blogs = blogRepo.fetch("recommend"); 
        // 在这里把广告数据整合到博客列表中 
        blogs = composeStrategy.compose(blogs, ads, transform); 
        callback.onLoaded(blogs); 
    } 
} 
public interface AdRepository { 
    List<BlogAd> fetch(String tag); 
} 
public interface BlogAdComposeStrategy { 
    List<Blog> compose(List<Blog> blogs, List<BlogAd> ads, AdBlogTransform transoform); 
} 
public interface AdBlogTransform { 
    Blog transform(BlogAd ad); 
} 

考虑到广告和博客可能有不同的整合策略，可以按需替换不同的实现，所以把整合策略封装到了BlogAdComposeStrategy接口中。整合策略也属于业务逻辑，但是因为整合策略的实现细节这里不需要关注，所以我觉得不写出来也行，反正都是我编的。

这里我想表达的是，获取广告数据并将广告数据整合到博客列表中也是业务逻辑的一部分，如果省略Model层将会造成得把广告的整合逻辑放到Presenter或者Repository层，这必然都是不合适的。将业务逻辑放到了错误的层次里，势必会造成后续的维护性和扩展性问题。

错误四：Model层依赖Presenter/ViewModel层

还有一些人没有搞清楚Model层和上层的依赖关系，依赖关系写成了双向的，这是不对的，业务层不应该依赖表现层，而是应该反过来。

实际上应该是Presenter/ViewModel通过接口的形式依赖Model层，Model层完全不依赖Presenter/ViewModel。就像我前面的示例代码里一样，Model层必然不会出现任何presenter这样的单词，上层通过观察者模式来监听Model层的数据变化(LoadCallback接口也算是一种)，Model层也不用关心上层是Presenter还是ViewModel。

最后

读到这里，不知道你们对MVX的理解是不是更深了些呢?对表现层逻辑、业务逻辑是不是也有了更清晰的认识了呢?

其实关于MVX还有更多可以讨论的，比如有些人认为Model层并不是真正处理业务逻辑的地方，它只是业务模块的一个上层封装层，我觉得也不无道理，在复杂业务模块中，业务是存在层次的，MVX中的Model层是所有业务层中的最上层。

还有我刚刚提到的业务层之下还有数据层，这是典型的三层架构的概念，即表现层、业务层和数据层。逻辑存在分层，所以架构也必然要进行分层，MVX可以做为我们从代码到业务甚至到架构的探索的开端。

（编辑：威海站长网）

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