app的组件化之路:业务组件化与中间件,MVVM架构的作用

简介: app的组件化之路:业务组件化与中间件,MVVM架构的作用

app发展的两个方向:组件化和新架构。

app组件化包括业务组件和中间件,它起到代码仓库隔离的作用,是模块化的具体应用,每个人通常分工时,做不同的模块从减少代码上传时的代码冲突。

MVVM架构是模块内页面的代码组织形式,能提高模块内页面代码的内聚性,提高代码的结构清晰性,易读性和开维护性。

组件化就是为了提高代码的重用率,架构是为提高具体功能页面的清晰性。组件化作用在文件级别,架构主要体现在页面级别,组件化对多app尤其重要,单app对架构更偏重。

业务组件可以是一个工程也可以不是。因为业务组件通常不需要对所有代码编译测试,它可能不能独立运行,一般不上传私有库,但是上传代码仓库。而私有组件和中间件一般都是一个工程,因为它通常能独立运行,内对所有代码编译测试,不然pod spec lint命令检查不通过,无法上传私有库或公有库。若业务组件能单独运行,等代码稳定了可以把它抽象成私有库。注意:我说的私有库是指通过严格的编译检查,通过pod repo push ******Spec上传私有源的工程仓库,不上传私有源的工程我们不称它为私有库。

业务组件是相当于主工程产生的。主工程一般负责引入和组织业务组件,公有组件,中间件,私有组件;还负责app工程启动与数据加载,登录逻辑等各个app经常变更的页面与逻辑,甚至包括根据请求结果进行架构切换的逻辑。业务组件只实现部分功能,一般业务组件项目不能独立运行全部它的全部功能,需要主工程引用和使用。若他能全部运行并使用它的全部功能,那么它就可以抽象成狭义私有库或中间件了。业务组件可以理解成是松耦合的文件结合,不要求独立运行。

中间件和私有组件:是严格约束的代码库,咱们和公有组件一样都能独立运行,能通过严格的pod spec lint检查。一般放在自己公司的gitlab上,一般也能放在github或码云上。为了保密和不付费,下载速度快,通常放在自己公司gitlab服务器上。中间件就是被其它的多个私有库或业务组件使用的一种私有库,它本质实际也是私有库。

新架构mvvm和组件化是软件工程的两个方面。组件化是指的项目文件的组织方式,而MVVM或MVP是对功能的具体实现与组织形式。所以组件化重在文件,MVVM重在功能。

MVMM一般分为实体类,View(页面元素),控制器,view-model负责具体的请求与参数填写与校验,请求结果的简单解析。所有只要在MVC的基础上抽象出view-model一般都属于MVVM,注意不是使用单例处理所有请求的方式。一般MVVM都使用ReactiveCocoa,大量使用信号和block。MVVM有很多实现方式,只要符合MVVM概念组织页面都属于MVVM架构。但是MVVM架构是有优劣的。

好的架构能让代码组织更清晰,更容易理解,但是决定代码好坏的不是架构,主要是人而不是架构。很差的架构有的人仍旧能写高质量的代码,有的人用最先进的架构写出低劣的代码都是很正常。千万别别指望所有的bug所有的人只要给时间修改就一定能消灭bug。有的人在修改一个bug时产生另一个bug,只是新的bug可能更难测试出来的bug。这个就要看这个人属于那种人了,也要看他的方案的完美性了。如:我们在一个页面请求成功弹出一个会消失的提示框并返回上一个页面。当使用MBProgressHUD等其它库加载在keywindow上,通常是看不到哪个提示框,测试就会给你提个问题单,很多人会采用延迟退出的方式,来让弹出框弹出后再返回。其实这样会降低用户体验,并且可能出现内存泄漏误报,甚至多次点击概率闪退等其它不可控问题,而且通常测试还测试不出来。当然最正确的解决方案是采用多window方案来实现跨页面显示。

程序猿有四类:

1.做的即慢质量又差的;2.做的即快质量又差的;3.做的慢但是质量好的;4.做的即快质量又好的。个性决定命运。若第一类三年升级不到3它走不到10年80%转行的命运;第二类人并不一定能变成第四类人,排除经验的原因外,很可能是性格使然,这类人通常更容易转行;第三类人通常能进入10年20%保留在本行业内;第四类人除了特殊原因,他们都是我们追求的目标,可惜这种人一般除了在程序猿这行业全能,通常更适合领导,10年不到他们大都去当领导去了。一般只有在它刚干这行的前五年才能见到这类人。所以招聘人就是招聘人和他的工作经验,组件化和架构是非必需条件,有更好。

看一下我们的业务组件化,中间件,公有组件在工程中的组织形式吧:

公有库

私有库和中间件

私有组件工程文件结构

业务组件工程文件结构

目录
相关文章
|
17天前
|
设计模式 存储 前端开发
MVVM、MVC、MVP三种常见软件架构设计模式的区别
MVC、MVP 和 MVVM 是三种常见的软件架构设计模式,主要通过分离关注点的方式来组织代码结构,优化开发效率。
38 12
|
1月前
|
前端开发
什么是MVVM架构?
MVVM是Model-View-ViewModel的简写。它本质上就是MVC的改进版。MVVM模式有助于将应用程序的业务和表示逻辑与用户界面 (UI) 清晰分离。 保持应用程序逻辑和UI之间的清晰分离有助于解决许多开发问题,并使应用程序更易于测试、维护和演变。 它还可以显著提高代码重用机会,并允许开发人员和UI设计人员在开发应用各自的部分时更轻松地进行协作。
32 2
|
5天前
|
移动开发 小程序 安全
基础入门-APP架构&小程序&H5+Vue语言&Web封装&原生开发&Flutter
基础入门-APP架构&小程序&H5+Vue语言&Web封装&原生开发&Flutter
|
11天前
|
前端开发 测试技术 API
探索安卓应用的架构演进:从MVC到MVVM
本篇文章将深入探讨安卓应用开发中的架构演进,特别关注从传统的MVC(Model-View-Controller)到现代流行的MVVM(Model-View-ViewModel)架构的转变。通过对比两种架构的设计理念、实现方式和实际应用案例,解析MVVM在提高代码可维护性和可测试性方面的优势。
17 0
|
1月前
|
前端开发 Android开发
Android架构组件JetPack之DataBinding玩转MVVM开发实战(四)
Android架构组件JetPack之DataBinding玩转MVVM开发实战(四)
Android架构组件JetPack之DataBinding玩转MVVM开发实战(四)
|
3天前
|
监控 持续交付 数据安全/隐私保护
Python进行微服务架构的监控
【6月更文挑战第16天】
27 5
Python进行微服务架构的监控
|
2天前
|
监控 Kubernetes API
探索微服务架构中的API网关模式
【6月更文挑战第22天】在微服务架构的海洋中,API网关是一艘引领航行的旗舰。它不仅是服务的守门人,更是流量的指挥官和信息的翻译官。本文将深入探讨API网关的核心作用、设计考量与实现策略,为构建高效、可靠的微服务系统提供航标。
|
2天前
|
JSON 负载均衡 监控
探索微服务架构中的API网关模式
【6月更文挑战第22天】在微服务架构的海洋中,API网关犹如一座灯塔,指引着服务间的通信与集成。本文将深入探讨API网关的核心概念、设计原则及其在现代后端系统中的关键作用,同时通过实例分析其对系统性能和可维护性的影响,为读者提供一种视角,理解如何高效地构建和管理微服务架构下的API网关。
|
1天前
|
Kubernetes 监控 Cloud Native
云原生架构下的微服务治理实践
【6月更文挑战第23天】在云计算的浪潮中,云原生架构以其弹性、可扩展性和高效性成为企业数字化转型的重要推手。本文将深入探讨如何利用云原生技术实现微服务的治理与优化,确保系统的稳定性和高可用性。我们将从微服务的基本概念出发,通过具体案例分析,揭示云原生环境下微服务治理的关键策略,并分享实践经验,旨在为读者提供一套完整的微服务治理解决方案。
|
1天前
|
设计模式 运维 监控
深入理解后端开发中的微服务架构
【6月更文挑战第23天】本文旨在探索微服务架构在后端开发中的应用及其带来的变革。通过分析微服务的核心原则、设计模式以及与传统单体架构的对比,揭示微服务如何优化开发流程、提升系统的可扩展性与可维护性。文章还将讨论实施微服务时可能遇到的挑战和解决策略,为后端开发者提供实践指南。