感谢您查看我的疑问.
我有个很多个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 类,代码也要多好多了.
不知道我的想法是不是有很严重的误区
我的每个页面逻辑都很简单300~500 行代码就可以搞定了,所以根本不想用MVP
请求网络的逻辑我不想放在抽象(V层抽象)里面
对于统一的错误处理,又需要在抽象里面解决,不然每个子类都需要自己再实现完全一样的对错误的处理,代码重复
感谢您查看我的疑问.
伊谢尔伦2017-04-18 09:20:47
之前接手到一个项目, 代码就是这么封装的. 后由于新版本产品需求, 导致原有代码根本无法使用. 无奈之下, 只能重构.
为什么要把网络调用封装进BaseFragment? 这么封装, 还能分得清楚返回数据是哪次调用产生的吗? 如果有业务需求需要区分, 那就很麻烦了. e.g.取消某次网络调用BaseFragment? 这么封装, 还能分得清楚返回数据是哪次调用产生的吗? 如果有业务需求需要区分, 那就很麻烦了. e.g.取消某次网络调用
除此之外, 如果你哪天想使用Retrofit了, 该如何是好?
这么封装弊端太多. 如果需要网络调用就直接调用就好了呀...
p.s. Activity/Fragment
除此之外, 如果你哪天想使用Retrofit了, 该如何是好?
Activity/Fragment是V层? 难道不是C层吗?伊谢尔伦2017-04-18 09:20:47
既然你已经把网络请求封装好了，那就直接使用吧，别再因为图省事而导致后续调试时带来麻烦。模块化分层的好处是显而易见的。假如你想把同样的处理都在BaseFragment中处理，那我推荐一个思路把，具体见下面的项目：
sealtalk
你着重看下他的网络调用途径，UML图中给出了，它实现了使用BaseActivity进行网络请求，当然请求代码被封装在其他的文件中，并且统一处理通用的错误，可以参考下。着重看下UML中提到的几个文件。
