MVC、MVP、MVVM架构设计的方式，在Android中广泛被使用。从本质上我认为，MVC和MVP其实将View层的代码解耦到Controller/Presenter中。随着业务的复杂，C/P中代码积累的多了，然后又开始解耦一些Model或Interactor或其他。随着业务再度复杂，每一个层的业务都很多代码了， 然后各种分层设计就出来了等等...
那回归到最简单的MVC、MVP模式来，我们可以发现这2个设计模式都产生了一个问题。
Controller和Presenter都需要持有View。View被各种传递。
能不能有一种方式能够同时解决解耦和值传递的问题？
由此我在实际项目中尝试 一种新的架构方式如下：
Widget:显示UI的页面级Widget，StatelessWidget或StatefulWidget。
ExtensionWidgetUI：Widget的扩展。这种专门存放了各种返回Widget的函数。
ExtensionWidgetController：业务的Controller，它也是一份Widget的扩展。但可以理解为处理业务的Controller。
ViewModel：这里我结合了Provider来使用。专门配合Controller使用，提供UI数据的支持。每一个ViewModel都mixin了一个LoadData。
LoadData：大部分情况下，页面都需要加载中、加载完成、加载失败等状态。所以这里维持了一份页面数据的加载状态，以提供给Controller、Widget访问。
如文件相关页面的代码：
Widget:
ExtensionWidgetUI:
这里相当于Android的XML了，专门提供UI组件。因为采用的是extension，所以完全不需要传递key、context等参数进去。它可以把自己当成Widget来生成各个UI部件。
ExtensionWidgetController：
Controller中使用获取页面数据，然后使用ViewModel更新UI完事，没什么多说的。...
ViewModel是在Widget中创建了，所以这里轻轻松松不用传值就可以拿到了。
但需要注意的是，请不要在以上2个extension中创建任何新的事物，如变量等等。
因为从使用extension的就代表了，它职位Widget而生，不能“做自己”。如果硬要创建，那IDE会报错如下.
ViewModel:就是你所理解的那种ViewModel，不讲了。
LoadData：只有这些，用来描述页面的状态，如果有人喜欢和ViewModel放在一起抽取出一个BaseViewModel出来也可以。
总结
由此，在我个人看来，不仅解决了MVC、MVP中Controller、Presenter 创建时需要传递一系列的参数进去的问题。而且实现了页面级的模块化，让不同职责的代码从一个StatefulWidget或StatelessWidget页面中解耦出来。同时，还不影响结合Provider等状态管理的框架的搭配使用。亲测目前暂无发现一些问题，如果发现什么致命问题还请留言指出问题，感谢。在Android开发中用了几年的MVC、MVP，不如来试试新的玩法？
