Android项目开发该如何选择架构模式？

时间：2018-07-17 19:23:53 阅读：142 评论：0 收藏：0 [点我收藏+]

标签：查找用户视图控制器软件阶段 ffffff 读取链接完美

小伙伴们，看到这个标题，映入脑海的是不是MVC、MVP、MVVM等这些熟悉的字眼？

首先我们要知道为什么要选择架构模式？

1、代码可读性好

2、框架的核心思想：解耦

3、方便测试

4、易于使用和维护性好

减少复杂性最简单的方法是将不同实体之间的职责分开。它应该遵循单一责任原则，应该有一个唯一的理由来改变；

为什么需要方便测试？

当一个有效的测试策略用于验证某些实现与其规范的一致性时，应用程序就被认为是可测试的。这些测试可以让开发人员在将应用程序交付给用户设备之前查找和修复错误。

为什么易于使用？

程序员都明白，编写的代码越少，错误的机会就越少；如果代码逻辑混乱，维护成本就会相应地上升，好的代码，即使一个新的开发人员接手，也可以轻松掌握。

MVC

Model-View-Controller是用于创建软件应用程序的广泛模式。目前还有很多应用程序和框架都实现了这种设计模式；

技术分享图片

Model层是域数据所在的位置，它管理读取和写入数据以及持久状态。诸如持久性、网络代码、模型对象和操纵数据的解析器等保留在这里；

View层是应用程序的面孔，是负责演示（用户界面）并处理用户交互的地方；

Controller层作为黏合剂，也就是Model层和View层之间的中介（模型和视图）。它通过对用户在View中执行的操作进行响应并更新Model层的数据来改变模型；

那么问题来了，如果我们使用MVC构建复杂的应用程序，就会变得困难重重；

随着时间的推移，越来越多的代码被转移到Controller，使它们更加脆弱和臃肿；

Controller与View紧密耦合，如果我们尝试在View中更改某些内容，我们必须回到Controller层并在那里进行更改，这违反了权限特征之间的均衡分配。

MVP

MVP代表Model-View-Presenter; Cocoa对MVC承诺可在MVP身上实现。它实现了可测试的和清晰的View和Model层分离。

技术分享图片

该Model层与MVC模型相同，它管理读写数据和持久状态，这部分没有变化。

View部分包括视图和视图控制器，此处的视图将用户交互委托给Presenter层，MVP中的视图可能比较愚蠢，并且不包含可以查询模型的逻辑。

Presenter层包含处理用户交互的逻辑，它的责任是与Model层进行通信，将数据转换为用户友好的格式，然后更新View层。

在MVP中，视图控制器被视为View的子类，而不是Presenter。责任分配在Model和Presenter之间，因为View不包含任何逻辑，从而实现均衡的特征分配。

我们不能说MVP是一个完美的模式，或者是不是应该遵循MVP，而不需要符合应用程序的要求；

MVP不适合简单的应用，它将导致编写样板代码从获得视图的接口开始工作。

MVVM

MVVM：视图模式之一。它代表Model-View-ViewModel；

ViewModel是观察者设计模式的实现，其中model中的任何更改都将在View和ViewModel中表示出来；

它包括：

Model：表示应用程序消耗的数据模型。此类声明属性以类似于上述两种设计的方式来管理业务数据。

View：它类似于MVP。MVVM视图包括视图和视图控制器。它只是保存数据并将所有内容委托给Model的层。

ViewModel：ViewModel作为模型和视图之间的链接。它负责包装模型并准备视图所需的可观察数据。

我们通过记住一些要点来使用MVVM：

view层很笨，只知道如何呈现数据。

controller对model层一无所知。

model不了解viewmodel。

viewmodel拥有model。

view controller拥有view。

controller拥有view model，并通过ViewModel与model层进行交互。

MVVM几乎满足了所有功能，该架构的责任分配在viewmodel和view之间；

使用MVVM的优点之一是可视性，因为视图模型与视图无关，因此每个实体都可以单独测试

这种模式不能用于简单的线性屏幕应用程序，否则可能会导致代码更复杂，新开发人员难以维护。
技术分享图片
各位老铁，你们觉得那种模式更好？

其实在我看来，这些模式都是非常经典和非常好用的，每种模式都各有优点，也各有局限性；

其实，换一种思路：

以现有的人力资源和时间资源，如何才能更快更好地完成需求，适当考虑下如何为后期扩展或重构做准备，可能这才是符合“国情”的一种选择！