网站后台搭建图文,上海有什么大企业,asp网站后台管理系统源码,怎么做宣传网页前言当我们接手一个项目的时候#xff0c;经常会发现一个activity或fragment动辄上千行甚至上万行代码#xff0c;这给阅读带来很大的困扰#xff0c;如果想读懂代码#xff0c;需要花费很多时间跟精力。引起这个问题的原因想必大家都了解#xff0c;随着人员不断变动经常会发现一个activity或fragment动辄上千行甚至上万行代码这给阅读带来很大的困扰如果想读懂代码需要花费很多时间跟精力。引起这个问题的原因想必大家都了解随着人员不断变动需求不断增多在没有严格代码规范的前提下每个人都是根据自己的偏好把需求做完最后是代码越堆越多维护性越来越差。为什么大家都喜欢往activity里面堆代码呢究其原因是因为android里面xml视图功能太弱activity不仅要承担视图显示还要加入控制逻辑承担太多职责代码就会越堆越多。在MVC之前有些人会考虑把activity的控制逻辑抽成Manager但是也没有一致的规范标准只是让代码看着清爽了些并没有从本质上把问题解决掉也就是View层跟controller层并未解耦。为了解决这个问题MVP出现了虽然可以代替activity处理大部分控制逻辑但是MVP也存在瑕疵代码量变大接口变多等因为Presenter要持有view的引用感觉两者并未完全解耦。此时MVVM出现了好像就是为了完善MVP的不足而设计的在这种模式下viewmodle跟view之间的交互是通过Data Binding来完成的Data Binding可以实现双向的交互这就使得视图跟控制层之间的耦合度进一步降低。一. MVCModel-View-Controller.pngMVC全称Model View Controller,如上图,是模型(model)-视图(view)-控制器(controller)的缩写,用一种业务逻辑、数据、界面显示分离的方法组织代码。其中M层处理数据,业务逻辑等;V层处理界面的显示结果;C层起到桥梁的作用,来控制V层和M层通信以此来达到分离视图显示和业务逻辑层。Android中界面部分也采用了当前比较流行的MVC框架,在Android中:视图层(View)一般采用XML文件进行界面的描述,这些XML可以理解为AndroidApp的View。使用的时候可以非常方便的引入。同时便于后期界面的修改。逻辑中与界面对应的id不变化则代码不用修改,大大增强了代码的可维护性。控制层(Controller)Android的控制层的重任通常落在了众多的Activity的肩上。这句话也就暗含了不要在Activity中写代码,要通过Activity交割Model业务逻辑层处理,这样做的另外一个原因是Android中的Actiivity的响应时间是5s,如果耗时的操作放在这里,程序就很容易被回收掉。模型层(Model)我们针对业务模型,建立的数据结构和相关的类,就可以理解为AndroidApp的Model,Model是与View无关,而与业务相关的。对数据库的操作、对网络等的操作都应该在Model里面处理,当然对业务计算等操作也是必须放在的该层的。就是应用程序中二进制的数据。一. MVPModel-View-Presenter.pngMVP框架由3部分组成:View负责显示,Presenter负责逻辑处理,Model提供数据。在MVP模式里通常包含3个要素(加上View interface是4个):View负责绘制UI元素、与用户进行交互(在Android中体现为Activity)Model负责存储、检索、操纵数据(有时也实现一个Model interface用来降低耦合)Presenter作为View与Model交互的中间纽带,处理与用户交互的负责逻辑。因此我们可以发现MVP的优点如下:1、模型与视图完全分离,我们可以修改视图而不影响模型;2、可以更高效地使用模型,因为所有的交互都发生在一个地方——Presenter内部;3、我们可以将一个Presenter用于多个视图,而不需要改变Presenter的逻辑。这个特性非常的有用,因为视图的变化总是比模型的变化频繁;4、如果我们把逻辑放在Presenter中,那么我们就可以脱离用户接口来测试这些逻辑(单元测试)。一. MVVMModel-View-ViewModel.pngViewView层做的就是和UI相关的工作我们只在XML和Activity或Fragment写View层的代码View层不做和业务相关的事也就是我们的Activity 不写和业务逻辑相关代码也不写需要根据业务逻辑来更新UI的代码因为更新UI通过Binding实现更新UI在ViewModel里面做(更新绑定的数据源即可)Activity 要做的事就是初始化一些控件(如控件的颜色添加 RecyclerView 的分割线)Activity可以更新UI但是更新的UI必须和业务逻辑和数据是没有关系的只是单纯的根据点击或者滑动等事件更新UI(如 根据滑动颜色渐变、根据点击隐藏等单纯UI逻辑)Activity(View层)是可以处理UI事件但是处理的只是处理UI自己的事情View层只处理View层的事。简单的说View层不做任何业务逻辑、不涉及操作数据、不处理数据、UI和数据严格的分开。ViewModelViewModel层做的事情刚好和View层相反ViewModel 只做和业务逻辑和业务数据相关的事不做任何和UI、控件相关的事ViewModel 层不会持有任何控件的引用更不会在ViewModel中通过UI控件的引用去做更新UI的事情。ViewModel就是专注于业务的逻辑处理操作的也都是对数据进行操作这些个数据源绑定在相应的控件上会自动去更改UI开发者不需要关心更新UI的事情。关于对UI控件事件的处理我们也希望能把这些事件处理绑定到控件上并把这些事件统一化方便ViewModel对事件的处理和代码的美观。为此我们通过BindingAdapter 对一些常用的事件做了封装把一个个事件封装成一个个Command对于每个事件我们用一个ReplyCommand去处理就行了,ReplyCommand会把可能你需要的数据带给你这使得我们处理事件的时候也只关心处理数据就行了再强调一遍ViewModel 不做和UI相关的事。ModelModel 的职责很简单基本就是实体模型(Bean)同时包括Retrofit 的Service ViewModel 可以根据Model 获取一个Bean的Observable( RxJava ),然后做一些数据转换操作和映射到ViewModel 中的一些字段最后把这些字段绑定到View层上。 上面三部分的分工很明确要不要把一部分逻辑放到activity 或者fragment来做是取决于你的提到的操作逻辑是什么如果这些逻辑操作是可以通过修改数据(这些数据绑定到UI)来更改UI或者你的操作逻辑是业务逻辑或者修改数据那么这块逻辑你完全可以在ViewModel 里面做。如果这些逻辑操作只是和UI有关而且不能通过Binding的方式更改数据源去反馈到UI(比如说 简单的对话框、PopupWindow等)是可以考虑放到View层去做但是如果这部分操作逻辑涉及到业务和数据相关的那么建议不用放到View层做View层主要职责是和UI相关的、没有数据没有业务。PS:该文章仅供自己学习之用
