Android Firebase Kotlin java Mvp Mvc Mvvm chat
1.0.0
MVC是Android中的一种干净的方法，将视图从控制器中脱颖而出。控制器仅负责更新模型，一旦模型更新了它可以通知视图，然后可以使用适当的回调更新视图。传统的MVC是有一个
模型：充当数据模型
查看：对用户的视图处理可以是UI
控制器：控制模型和视图之间的相互作用，其中视图调用控制器以更新模型。视图可以在需要时调用多个控制器。
可以使用MVP方法克服MVC的一些缺点。 MVP中的主持人包含所有业务逻辑，此类远离Android上下文或与Android相关的依赖关系，这些依赖性可通过简单地在测试模块中使用演示者类，从而为文本业务逻辑提供灵活性。与Android相关的依赖性在测试中创造了复杂性。主持人没有任何Android依赖性，例如上下文，视图等，所有模型更新和网络请求都是通过主持人完成的。模型更新或网络请求完成后，使用回调通过主持人来更新视图，以查看主持人。没有模型和网络请求可以直接访问视图。
MVVM涉及一种数据绑定方法，以使代码简短并减少Java类中的视图处理代码。视图模型负责更新视图，并且一旦将视图模型绑定到视图，则视图获取有关其更新事件的通知。如果模型通过用户单击更新，则将模型发送回调以查看模型，该模型会在视图绑定时自动更新视图。 MVVM降低了代码大小，但MVVM的实施非常困难，很难根据MVVM调试大型项目。
？
为该项目选择正确的体系结构涉及对需要开发的模块的理解。某些功能在MVC上效果很好，有些功能具有MVP，有些功能具有MVVM。很难在MVVM上进行调试，特别是由于数据绑定和实时数据而没有单方面数据流的项目。如果应用程序从源接收连续的数据流，则需要常规的UI-UPATE，并且主要具有（80-90％）的单面通信（例如：将日志发送到Android应用程序的电子设备（例如太阳能电池应用程序），例如太阳能电池应用程序，Interverters应用程序，或任何其他设备的状态可与MVVM一起良好，因为实时数据可以很好地工作。调试这些MVVM应用程序可能很容易，因为大量数据流是单方面的。
当我们担心通过Java测试框架（非Android）测试业务逻辑WRT单元测试时，MVP是编写Android项目的好方法。由于Java测试框架只能解析Java依赖项，并且干净的演示者层没有与Android相关的依赖项，例如上下文，共享Preferences或任何其他com.android。 * 包裹。 MVP的缺点是，它最终以使用MVC或MVVM编写的相同功能编写20-25％的额外代码。如果您真的对模块的测试用例和单位测试感兴趣，则MVP很好。对于使用Java测试套件的MVP，只需制作主持人实例并运行测试功能即可。
例如：新主持人（）。testSomeFunction（） 。
MVC是在Android中广泛使用的技术。 Google本身在MVC中写了它的存储库多年了。现在，Google正在为其GitHub存储库采用MVVM，因为这些存储库很小，主要是样本。由于缺乏com.android的依赖关系，因此可以通过不使用Java特定测试工具的Android测试框架来测试MVC应用程序。 * Java特定工具中的软件包。
例子：
注意：没有一个最好的体系结构。如果有一个，就不需要学习其他架构。正确的体系结构的选择取决于几个因素，例如初始需求，数据流，可伸缩性，维护，更新（CRS），测试要求。
除了这三个Android体系结构外，还有另外一个称为“ MVI - 模型视图意图”的体系结构。这在Android开发人员中不是很受欢迎。如果您对MVI感兴趣，请检查此链接。
https://github.com/saksham24/android-simple-mvi-pattern-with-mvp-mvvm-collaboration
