Android-Daily-Interview
Android-Daily-Interview copied to clipboard
Moosphan
2019-04-19：请谈谈你对 MVC 和 MVP 的理解？
-
MVC 是常用的软件开发架构，但是android中对activity的定位不明确，mvc写法常常会将业务逻辑和视图逻辑都混合在一个activity类中，造成代码逻辑混乱，随着项目增大，维护成本会几何倍增加。
-
MVP 也不是新东西了，主要思想就是将业务逻辑从activity中割裂出来，保证职责的明确，依赖关系可以简单的这样表示 M==>P<===>V ,M只负责获取数据，p只从m拿数据而不关心数据获取的流程，p 会有v的引用，从而发送消息给v ，v需要数据时只需要调用p而不需要知道p对数据的操作。
-
mvp的之间的依赖不是一定的，每个人对一个事物都会有自己的见解，但是万变不离‘职责明确’这四个字
-
mvc使用： 项目小 开发进度需求快，直接莽，用mvc没关系，技术是为了完成业务的 。
-
mvp使用：中大型项目，最好配合模块化，将粒度分的更细更清晰，写起来需要多人配合，不然会稍慢
主要区别：区别在于MVP中 view层更独立，相比较mvc 解耦性更高 在mvc中view既要承担view的视图角色，又要承担业务逻辑的角色，随着业务的增多，导致逻辑不够清晰，代码臃肿；mvp p层承担了大部分逻辑 v层变得更纯粹
MVC对android来说 activity几乎承担了view层和controller层两种角色，并且和model层耦合严重，在逻辑复杂的界面维护起来很麻烦 MVC演变而来，MVP模式下的activity只承担了view层的角色，controller的角色完全由presenter负责，view层和presenter层的通信通过接口实现，所以VP之间不存在耦合问题，view层与model也是完全解耦了。相对于MVC来说，MVP后期更易于维护。
对于android开发来说，由于activity本身的定位问题，用mvc上，对于稍大的项目，不可避免的会导致业务逻辑与界面逻辑相互掺杂在activity中，使后期维护产生困难。 mvp来说的话就是职责更明确了，将原来mvc下的activity分成了两部分，一部分为只负责view层逻辑的，一部分通过p层联系view层和model层 对于不是很大的项目来说，使用接口定义的mvp模式，容易造成接口管理的困难，类的爆炸，代码量的增加。 所以mvp虽好，但是还是要按需选择
1.MVC 用户首先通过View发起交互，View调用Controller执行业务逻辑，Controller修改Model，然后View通过观察者模式检测到Model的变化（具体表现形式可以是Pub/Sub或者是触发Events），刷新界面显示。 从这里可以看出，主要业务逻辑都在Controller中，Controller会变得很重。MVC比较明显的缺点：
- View依赖特定的Model，无法组件化
- View和Controller紧耦合，如果脱离Controller，View难以独立应用（功能太少）
2.MVP 为了克服MVC的上述缺点，MVP应运而生。在MVP中，View和Model是没有直接联系的，所有操作都必须通过Presenter进行中转。View向Presenter发起调用请求，Presenter修改Model，Model修改完成后通知Presenter，Presenter再调用View的相关接口刷新界面。这样，View就不需要监听具体Model的变化了，只需要提供接口给Presenter调用就可以了。MVP具有以下优点：
- View可以组件化，不需要了解业务逻辑，只需提供接口给Presenter
- 便于测试：只需要给Presenter mock一个View，实现View的接口即可
如果是前端开发的话还有MVVM和Flux，这里就不赘述了，可以参考这篇：https://0x9.me/05XTk
- MVC:model,view,control。在Android开发中。传统的MVC写法大多是把view和control写在一起，也就是我们常见的Activity和Fragment文件里。这样的缺点就是造成这两个页面代码量比较大，而且业务逻辑和view耦合在一起。一旦需求变更维护成本会比较高。
- MVP:与MVC相比，MVP将业务和UI解耦。view触发业务，prensenter处理业务并且将结果反馈给view。View便可以根据业务的处理结果直接显示相应UI。这样的好处就是，业务和ui解耦，当需求变更时，只要处理相应的方法便可。
如果做Android的话，我建议还是MVVM，不过现在谷歌提供的dataBinding有点蛋疼，每次修改布局还要重新rebuild下。期待有其他解决办法。
MVP架构可以去类比一个公司的组织架构，V层就像销售直接面对客户，P成就像产品和项目经理，M层就像开发人员。V层接收具体的事件交给相应的P产品和项目经理，P负责具体的控制分发交给M具体人员去处理。V与P ，P与M之间都有专门的沟通渠道来反馈彼此信息。
MVC架构将视图和数据进行分离，但是View既要与model(数据层)通信,也要与Controller(控制器)通信，既当爹又当妈，这样的话，随着项目较大时，维护改动的成本就会很高，因为它们之间耦合性比较高。所以MVP框架补了这个坑，在MVP里，View层与Presenter(主持层)进行通信，Persenter又与model层进行通信，这样当View变化的时候，Persenter就相当于一个中间人，负责将数据储存到model，也负责通知View层进行变化，这样就避免了View与model的直接接触。但在我们实际开发中，如果项目本身不是特别复杂，mvc更简单明了点。
原有的MVC模式中，Activity同时从Activity中view和controller的代码集合到一起会很臃肿，MVP，view从Activity抽出UI逻辑，P从Activity抽出业务逻辑，负责view和model的数据通信，实现view和model的分离。
大家认为的MVC 和 MVP区别
MVP 是把控制器或者调度器给拆出来了 MVC 是把View给拆出来了 本质目录结构都是一样的,一个调度源,一个显示源,一个数据操作源
我认为
- 大家认为的MVC是错误的,MVC的概念是在Java里面提出来的,在strus2里面有深刻体验,在客户端开发里面,M 与 V和C 分离不够明确,但是MVP Presenter,和 Model View实现了真正意义的隔离,android里面的MVC不是严格意义的MVC,但是MVP确是Java概念所理解的MVC
- MVC 和 MVP 没有区别,MVP 和 MVC 本质是一样的
- 但是MVVM确是大家一致认同的,MVVM是一个加了双向绑定的MVP
- MVC 和 MVP 的架构优势和实现方式: 逻辑的独立互相不干扰,其中本质不同是,拆Controller和拆Prensenter
MVC 与 MVP 主要区别
本人也是菜鸟一枚，以下结合楼上各位大佬的讲解简单说一下：
MVC
M(Model) V(View)对应于我们的Layout, C(controller)控制层，相当于我们的activity or fragment
其实一直来android xml这个所谓的View层无法像vue中的html一样承载过多的逻辑操作；所以在mvc中，activity/fragment做为controller，既承担了view的页面显示功能，又承担了控制层控制逻辑的内容；
MVP
- 将activity/fragment与layout共同做为view；
- 抽离view层代码占比；present增加代码权重，基于接口定义较多case场景，通过实现接口，p层调用m层提供的case实例，得到数据；
- M层和View完全解耦
MVC： Model：主要用于网络请求、数据库、业务逻辑处理等操作。 View：用于展示UI，一般采用XML文件进行界面的描述。 Controller：控制层的重任落在了众多Activity上，Activity需要交割业务逻辑至Model层处理。 事件从View层流向Controller层，经过Model层处理，然后通知View层更新。 缺点： a.Controller层，也就是activity承担了部分View层的职责，导致该层过于臃肿。 b.在MVC中，Model层处理完数据后，直接通知View层更新，因此MV耦合性强。
MVP： Model：数据处理层。 View：视图显示层。 Presenter：业务逻辑处理层。 通过接口，V和P间接相互持有引用，P和M间接相互持有引用，但是V和M完全解耦，而且把业务逻辑从activity中移到P中，减轻了activity的压力。 缺点： 当View层足够复杂的时候，View接口会变得很庞大。
MVVM： Model：同上。 View：同上。 ViewModel：视图模型，通过框架实现View层和Model层的双向绑定。 优点： a.View和Model双向绑定，一方的改变都会影响另一方，开发者不用再去手动修改UI的数据。 b.不需要findViewById也不需要butterknife，不需要拿到具体的View去设置数据绑定监听器等等，这些都可以用DataBinding完成。 c.View和Model的双向绑定是支持生命周期检测的，不会担心页面销毁了还有回调发生，这个由lifeCycle完成。 d.不会像MVC一样导致Activity中代码量巨大，也不会像MVP一样出现大量的View和Presenter接口，项目结构更加低耦合。 缺点： 由于数据和视图的双向绑定，导致出现问题时不好定位来源，有可能数据问题导致，也有可能业务逻辑中对视图属性的修改导致。
选择： 1、如果项目简单，没什么复杂性，未来改动也不大的话，那就不要用设计模式或者架构方法，只需要将每个模块封装好，方便调用即可，不要为了使用设计模式或架构方法而使用。 2、对于偏向展示型的app，绝大多数业务逻辑都在后端，app主要功能就是展示数据，交互等，建议使用mvvm。 3、对于工具类或者需要写很多业务逻辑app，使用mvp或者mvvm都可。
MVC：android天然的架构模式，但是activity可以直接引用model层，存在一定的耦合性。android的VC也区分不够明确 MVP：将M和V隔离开来，通过接口通信，职责更加明确，业务逻辑全部在P层实现，V层操作xml控件逻辑 MVVM：dataBinding实现xml和ViewModel的双向绑定，通过LiveData viewModel只关注业务逻辑，并且与View层完全解耦
不管是MVC还是MVP模式都是为了解决项目中的高聚合和低耦合 MVC 将逻辑 数据和业务逻辑分离的一种框架模式 Model模型层：业务逻辑处理和请求数据处理层 View视图层：代表布局文件 Controllor控制层：代表Activity 负责加载View层布局和调用Model层返回结果并响应 优点： 视图层和Model结耦 通过Controllor来控制 职责划分明确 主要划分M V C三个模块 代码实现简单 缺点 逻辑复杂会导致Activity 代码过于臃肿 并且View和Model还会有交互 并没有做到分离 这就会产生耦合 MVP Presenter层把Model和View层做分离 View层不能直接调用Model层 而是通过以Presenter层做桥梁去调用 Model处理数据模型直接把模型返回Presenter层 然后由Presenter层回调View展示界面 Model模型层：业务逻辑处理和请求数据处理层 View视图层：代表Activity 只做界面展示和调用P层交互 P：Model层和V层之间交互的桥梁 优点： MVP的出现解决了MVC的View和Model之间的耦合 实现了完成将View和Model做分离 缺点：代码实现复杂 适用于中大型项目
