MVC架构分析
在项目开启阶段,其中一个很重要的环节就是选架构,今天来谈谈MVC这种最常用的架构模式。
M是指业务模型,V是指用户界面,C则是控制器
MVC架构的任务分工为:
(1)M-model:
1.数据结构表示
2.读取本地数据
3.写数据到本地
4.处理弱业务
(2)C-Controller:
1.处理主要业务逻辑
2.处理交互事件
3.协调V-M数据流
(3)V-View:
1.展示数据
2.处理非逻辑交互事件。
根据上面描述,总之一句话概括:
M:管理数据, C:处理数据, V:展示数据。
使用MVC的目的是将M和V的实现代码分离。
MVCS
看名字就感觉这个MVCS架构模式是从MVC中分化出来的,事实上也确实如此。
S为Store的简称,意思为“存储,保存”。
下面来看一下多出一个S后,它们的分工有什么变化呢?
(1)S-Store:
1.负责数据的存储,数据本地持久化。
M-Model:
1.数据结构表示
2.读取本地数据
3.处理弱业务
(2)C-Controller:
1.处理主要业务逻辑
2.处理交互事件
3.协调V-M数据流
(3)V-View:
1.展示数据
2.处理非逻辑交互事件。
从上面的分工可知C,V同MVC架构是完全一样的,只有M的数据存储任务被分离了出来。即:S分担了M的数据管理任务,那么M和S其实都是数据管理的逻辑范畴了。
根据上面描述,总之一句话概括:
(M+S):管理数据, C:处理数据, V:展示数据。
MVVM
MVVM为了解决前端的响应式编程而生,由于前端网页混合了HTML、CSS和JavaScript,而且页面众多,代码的组织和维护难度复杂,所以通过ViewModel实现View和Model的双向绑定。
但是移动端不是前端,从业务处理逻辑上讲,移动端要比前端处理的逻辑更多,你问我有啥依据。你可以把手机的网断掉,进入带有离线功能的APP,一套业务走下来,没啥问题。但是用浏览器打开呢,纵然添加了缓存,也是不能将一套业务走完的。
所以说,移动端要比前端处理的逻辑多!
看到MVVM你会有疑问,为啥没有C了,是不是用这个MVVM就不需要C了呢?如果你是移动端的同学,我给你讲是有C的。
MVVM架构在移动端的完整叫法是:M-V-C-VM。
MVVM架构的任务分工为:
(1)M-model:
1.数据结构表示
2.读取本地数据
3.写数据到本地
4.处理弱业务
(2)C-Controller:
1.处理交互事件
2.协调V-M数据流
(3)V-View:
1.展示数据
2.处理非逻辑交互事件。
(4)VM-ViewModel:
1.处理主要业务逻辑
从上面的分工可知,VM分担了C中的数据加工任务,将业务处理放到了ViewModel中,其他的M,V同MVC架构完全一样。
总之一句话概括:
M:管理数据, (C+VM):处理数据, V:展示数据。
MVP
MVP从MVC衍生而来,从名称上看只是将C换成了P。其他都一样。而事实上呢?
它们也确实这样,P承担了C的任务而已。
区别是:它们两个的数据流向不一样
对比一下,就可以一样看出了。
MVC框架中,V的数据从Model中拿
MVP框架中,V的数据从Presenter中拿。
MVP架构的任务分工为:
(1)M-model:
1.数据结构表示
2.读取本地数据
3.写数据到本地
4.处理弱业务
(2)P-Presenter:
1.处理主要业务逻辑
2.处理交互事件
3.协调V,M数据流,从M读取数据,将数据通过接口供V调用。
(3)V-View:
1.展示数据
2.处理非逻辑交互事件。
根据上面描述,总之一句话概括:
M:管理数据, P:处理数据, V:展示数据。
架构从逻辑分层上讲,常见有两种:
三层架构:展示层,业务层,数据层。
四层架构:展示层,业务层,网络层,本地数据层。
架构从任务分配上讲,常见有五种:
MVC、MVCS、MVVM、MVP、VIPER
而通常在工程中,这两个维度的思想是同时存在的。
比如:三层MVC架构,四层MVC架构。
前面的层级表示逻辑分层方式
后面的形式表示任务分配方式
通过上面五种架构责任划分的介绍,我们可以知道
无论是什么架构模式,它们的区别是:任务的分配方式不同罢了。
虽然我们在任务分配后的文件和目录四不像,但是可以满足我们的业务需求和功能扩展,这就够了。
不要被形式上所限制。
那么什么是好的架构模式呢?
个人认为比较好的架构模式为:三层MVC架构
任务分配方法是以MVC任务分配方案为基础,按照一定的原则进行个性化分配。
采用如下分配原则:
1.保留当前角色的主要功能,拆分次要功能。
2.弱业务功能放到Model中,尽量不要放到Controller里去。
3.拆分出去的业务功能尽量封装成可复用组件、对象或协议。
4.控制好拆分粒度,调用接口少参或无参。
W Y: Layer层可能是USD最具有创新性的功能。从概念上讲,与PS中的层有相似之处:最终的合成是按顺序组合所有层的效果和结果。但是,USD的层不是修改图像的像素,而是修改合成场景的属性。最重要的是,他们提供了强大的协作机制。
W Y: 国内在用此格式的公司 : 华为:18还是19年开始做的Cyberverse河图引擎。 育碧:内部消息今年十月底刚刚搞了一个组专门推USD。 OpenUSD(Open Universal Scene Description)是一种开放的、可扩展的场景描述格式,目前被广泛用于电影、动画和虚拟现实等领域。 OpenUSD的互操作性是最重要的优势之一,这使得它成为了跨不同软件和工具之间进行数据交换和协作的理想选择。其实它本身根本不只是一个格式这么简单,你可以把它理解成一个用来定义格式的工具和运行时。它底层提供了一系列技术支持以组合的形式动态地对数据进行编码解码。像过去,我们把数据编码成字符串给别人,别人要跟你通气做解析器去解码你的数据。如果我这边数据格式有任何变动,变了你就要更新代码,数据总是会变的,我们就要对来对去。而USD的思路是你可以通过它的统一运行时帮你做解析,你不需要再去编码解码了。如果你说这样不安全,那其实它同时还有分层的技术帮你处理安全与权限的问题。USD最重要的设计目标之一就是协作。它的组合思想体现在方方面面。不只是一个文件里的数据时组合的,你可以把数据单独保存成USD文件并且在他们之间创建联系,这样不同的技术人员或者团队就可以用多个的不同的软件来读取和编辑数据,来进行协作。非常大地简化了数据转换和重新导入的过程,提高团队之间的效率。另外,数据存储和加载方面性能也很强,它支持增量加载、增量更新。而且他还有实例化、引用等技术让数据可以复用。说到底,就是这种互操作性让USD成为了跨软件和平台的理想选择。
W Y: Omniverse Kit 是一个软件开发平台。该平台包含了各种用于构建元宇宙应用、扩展程序和微服务的功能和构件 ,并且这些功能和构件正在不断增加。
W Y: Unity引擎: 优点: 简单易用:Unity拥有友好的用户界面和强大的编辑器工具,使得初学者和非技术背景的开发者能够快速入门。 跨平台支持:Unity支持多个平台,包括Windows、Mac、Linux、iOS、Android等,使开发者能够轻松发布游戏和应用到不同的平台上。 社区支持和资源丰富:Unity拥有庞大的开发者社区和资源库,可以找到大量的教程、示例代码和插件,加快开发速度。 2D和3D游戏开发:Unity在2D和3D游戏开发方面表现出色,提供了丰富的工具和特性,支持各种游戏类型的开发。 缺点: 性能:相对于UE引擎,Unity在处理大规模、高度优化的图形和物理效果方面的性能略有不足。 图形质量:Unity的默认渲染效果和图形质量可能不如UE引擎那么出色,但可以通过自定义着色器和特效进行改进。 Unreal Engine引擎: 优点: 强大的图形渲染:UE引擎以其出色的图形渲染能力闻名,提供了高品质的视觉效果和逼真的渲染。 物理模拟和碰撞检测:UE引擎内置了强大的物理引擎,可以实现真实的物理模拟和高度准确的碰撞检测。 蓝图系统:UE引擎的蓝图系统使得非程序员能够使用可视化脚本创建复杂的游戏逻辑和交互。 VR/AR支持:UE引擎提供了广泛的虚拟现实和增强现实支持,使得开发VR/AR应用变得更加容易。 缺点: 学习曲线陡峭:相对于Unity,UE引擎的学习曲线较陡峭,需要更多的时间和技术背景来掌握其高级功能和工作流程。 复杂性:UE引擎的功能和工具非常丰富,但也使得项目变得更加复杂,对于小规模项目可能显得过于庞大。 资源消耗:由于UE引擎的高度逼真的渲染和物理效果,它对计算机硬件的要求更高,可能需要更强大的计算机配置来进行开发和运行。 总结来说,Unity适用于初学者和小规模项目,它易于上手、跨平台,并且具有强大的2D和3D开发工具。Unreal Engine适用于需要高品质图形和物理模拟的项目,它提供了强大的图形渲染和物理引擎,并支持复杂的虚拟现实和增强现实应用。选择哪个引擎取决于项目的需求、开发团队的技术能力和资源限制。
weixin_m1132442666: 能不能实现多账号对一个商品批量下单