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

什么?你这个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类去获取数据呢?

（编辑：天津站长网）

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