android - 我不想在V层的抽象里请求网络,有什么办法吗?

Question

感谢您查看我的疑问.

我有个很多个fragment(我的V层)
他们里面都有请求网络的操作,他们通常只会关心请求成功的数据

所以我就抽取了一个BaseFragment 在这个BaseFragment 里面,将请求网络时的进度显示,失败处理 做了统一处理,那么在他的子类中就只需要关心请求成功后的数据了.

但是我发现这样做的话,代码量的确是下降了很多,请求网络的时候我的fragment 也只需要调用父类的类似requestData(String request) 的方法,传入对应的request就可以在类似onRequest(JavaBean bean) 中获得需要的对象了.

但是这样做的话,我总感觉有哪里不对,不清楚是不是因为我把请求网络直接放在了BaseFragment里面,如果这样的话,我再设计一个请求网络的util 类,每次请求的时候需要将BaseFragment 的引用(this)传入,然后在util 中的合适的位置对BaseFragment 的实例进行操作.把请求网络的抽象都放在util 中,共性直接就可以在util 中完成.

但是这样做也只是多了一个类,这个util 只为BaseFragment 服务,基本和原本没什么区别.所以我认为我的代码还是有很大问题的.

顺便问一下,如果是MVP 架构的话,是怎么在P层调用M层请求网络数据的时候,处理V层进度和失败的呢? 每次请求网络都要带着V层引用传递过去?如果这样做的话代码写起来不是非常难看?如果不传递过去,那么比如失败处理不是每次请求都需要在失败的位置又从P 层通知V层? 如果是小项目的话原本可能300~500行的代码,这样做的话可能就要多3~5 类,代码也要多好多了.

不知道我的想法是不是有很严重的误区

1. 我的每个页面逻辑都很简单300~500 行代码就可以搞定了,所以根本不想用MVP

2. 请求网络的逻辑我不想放在抽象(V层抽象)里面

3. 对于统一的错误处理,又需要在抽象里面解决,不然每个子类都需要自己再实现完全一样的对错误的处理,代码重复

感谢您查看我的疑问.

Answer 1

이전에 프로젝트를 맡았는데, 코드가 이렇게 캡슐화되어 있었는데, 나중에 새로운 버전의 제품에 대한 요구로 인해 원래 코드를 전혀 사용할 수 없었습니다. 리팩토링만 가능합니다.

1. 네트워크 호출을 BaseFragment으로 캡슐화해야 하는 이유는 무엇입니까? 이 캡슐화를 통해 반환된 데이터가 생성된 호출을 명확하게 구분할 수 있습니까? 예: 특정 네트워크 통화 취소

2. 게다가 언젠가 Retrofit을 사용하고 싶다면 어떻게 해야 할까요?

3. 이렇게 캡슐화하면 단점이 너무 많습니다. 네트워크 호출이 필요한 경우 직접 호출하면 됩니다...

p.s. Activity/Fragment레이어 V 아닌가요?

참고:

• Android의 MVC, MVP, MVVM

• MVC에서 Activity 클래스의 역할은 무엇인가요?

Answer 2

이제 네트워크 요청을 캡슐화했으므로 다이어그램이 편리하므로 후속 디버깅에 문제가 발생하지 않도록 직접 사용하세요. 모듈식 레이어링의 이점은 분명합니다. BaseFragment에서 동일한 처리를 처리하려면 아이디어를 권장합니다. 자세한 내용은 다음 프로젝트를 참조하세요.
sealtalk
UML 다이어그램에 나와 있는 네트워크 호출 경로에 집중해야 합니다. 물론, 요청 코드는 다른 파일에 캡슐화되어 있으며 일반적인 오류는 아래에서 참조할 수 있습니다. UML에서 언급된 여러 파일에 초점을 맞춰 보겠습니다.

Answer 3

인터페이스를 캡슐화하고 URL 및 이름을 포함한 엔터티 클래스 Api를 추가합니다.
Api를 각 요청의 매개변수로 사용하고 반환
통합 요청 콜백에서 Api를 사용하여 어떤 요청인지 구분합니다