关于MVC/MVP/MVVM的一些错误熟悉
副问题[/!--empirenews.page--]
在Android开拓中行使MVP和MVVM模式早已不是奇怪事了,各类MVP/MVVM相干的文章、开源库也已多如牛毛,乃至是让人目眩撩乱,那么我为什么还要在这个早已被画满涂鸦的黑板上再来涂涂画画呢?是想彰显我的存在感吗?那虽然!啊不不不……不完满是!我还想要警觉读到这篇文章的列位:你们对付MVX的领略也许并不完全正确! 注:这篇文章里我将行使 MVX 做为MVC、MVP以及MVVM的统称。 我们都知道MVX的进化进程是从滚球兽进化到MVC,然后从MVC进化到MVP,再从MVP超进化到MVVM。那么接下来,凭证通例的套路,我应该要先容什么是MVC,什么是MVP,以及什么是MVVM,而且别离先容M、V、C/P/VM各自的职责了。 我的目标是想要更正一些对MVX的错误熟悉,以是条件是你要对MVX有一些相识。为了停止有人在行使MVX时走上弯路,以是抉择对我看到的一些关于MVX的错误熟悉举办总结以及更正。会发生这些错误认知的缘故起因,经我说明,着实是:没有真正了解到MVX主义的焦点代价观!着实MVX的焦点头脑也很简朴,不要误会,不是兴旺、民主、……而是 将示意层和营业层疏散 。 示意层和营业层疏散 示意层和营业层疏散,Matin Fowler称之为Separated Presentation。这里的示意层就是VX,营业层就是M。假若有人看到这里发明白和你以为的MVX纷歧样的话,那么你对MVX的熟悉很也许就存在错误,严峻者还大噶?鲞了批改主义蹊径! 从示意层和营业层疏散的视角来看,M、V、X不是划一的身份,应该是M和V-X。自始自终M的职责都没变,变的是V-X,跟着软件开拓技能的成长、交互情势可能交互前言的不绝改变,示意层的逻辑也越来伟大,MVX的进化进程就是一个不绝探寻处理赏罚示意层伟大逻辑的进程。虽然从一个形态进化到另一个形态,并不必然是为了办理更伟大的交互逻辑,也也许是有了一种“更优雅”的方法来处理赏罚示意层逻辑。 既然已经有示意层和营业层疏散的观念了,那么第一个错误概念就很好表明白。 错误一:Presenter可能ViewModel认真处理赏罚营业逻辑 这是一个很常见的错误概念,许多先容MVP可能MVVM的文章都这么说过。正如前面所说,营业逻辑是属于M层的,那Presenter可能ViewModel是干什么的,处理赏罚示意层逻辑的吗?是的,可能说大部门示意层逻辑都是在Presenter可能ViewModel中处理赏罚的。之前我将营业层之上的这些逻辑称之为视图逻辑,此刻为了同一就叫做示意层逻辑吧(加个吧字怎么感受怪怪的)。 我在这里就简朴说一下什么是示意层逻辑,以及View和Presenter/ViewModel又是怎样分工的。假设你的应用有一个小我私人资料的profile页面,这个页面有两种状态,一种是赏识状态,一种是编辑状态,通过一个编辑按钮触发状态的转换,编辑状态时,部门信息项可以举办编辑。那这里就有一个明明的示意层逻辑,那就是点击按钮切换赏识/编辑状态。 此刻的MVP的风行形态(可能变种)叫做Passive View,它和MVVM一样此刻都倾向于将险些全部的示意层逻辑交给Presenter可能ViewModel处理赏罚,View层必要做的工作很少,根基上就是接管用户变乱,然后将用户变乱转达给Presenter可能ViewModel。以上面的profile页面的例子来表明的话就是,View层认真吸取编辑按钮的点击变乱,然后关照Presenter/ViewModel,然后Presenter/ViewModel关照View是表现赏识状态的视图照旧编辑状态的视图。MVP的示例代码或许是这样的:
注:这个示例代码只是为了展示示意层逻辑,没有涉及到Model层,编译也不会通过的! (编辑:湖南网) 【声明】本站内容均来自网络,其相关言论仅代表作者个人观点,不代表本站立场。若无意侵犯到您的权利,请及时与联系站长删除相关内容! |