关于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可以做为我们从代码到营业乃至到架构的试探的初步。

（编辑：湖南网）

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