2回答

雷宇

2018-11-07

已采纳

你好，这是一个非常好的问题。

首先说一下repository，它代表的是数据层，数据的来源可能是网络，可能是SD卡，或者数据库等，它本身并不处理业务。从设计上来讲，它应该是以接口的形式出现，然后具体的来源去实现它，由于我们课程都是从服务器获取数据，所以就直接使用的是实现类。

再说Model层，在课程里就是service层，业务层主要是处理业务逻辑，它和数据层唯一的交互就是去获取数据，如果一个业务需要同时获取多个数据源，再统一处理，就需要引入多个repository，同样的，课程里边都是单线的业务，所以看上去会让人觉得很多是多余的，这点主要是大家在实际项目中自己去根据需要扩展。

它们之间唯一的耦合应该是repository没使用接口，这点可能使用接口来做，再配合Dagger，就没什么耦合度了。

最后说一下，课程里把所有业务都拆开了，确实service没有存在的必要，但是大家在真实项目中，实际情况会比这个复杂，需求变动比较大的话，建议数据层拆离，并使用接口实现。

1

1

xiaobai00000

非常感谢！

2019-01-11

共1条回复

xiaobai00000

提问者

2018-11-01

排版不好了，我重新写下：

老师您好，我有个问题。 就基于大型项目而言，为什么要在module层中抽出repository层？ module层本来不就是 处理业务的么，现在再抽一层出来，感觉module并不是轻量了，而是分成两个或者多个了。

看了您之前说:一个module可能 引用了多个repository层（能否举个例子呢）。但是我认为 module是base on 业务层的，比如遵循RestFul的 api接口， 就分为 user, pay，goods等，每一个part都有且只有一个module不好么？  能不能直接把repository作为module,service没有必要.(因为之前看google 的sample,貌似也是repository作为module的)。  如果项目大，每一个module都分成service+repository，工作量大，而且service 和 repository耦合很高，要改基本都得改啊。

0

0