一、概述
- MRCV框架是针对游戏客户端业务功能开发，对显示层和数据层设计中的具体问题提出解决方案，并以简化外层工作、提升迭代速度为主目标的设计模式框架。
- MRCV框架作用于代码、资源、设计和所有相关工作流。
- MRCV依赖于设计的合理抽象。MRCV适用于任意复杂度的项目和功能。
明确MRCV框架的目标和定义、作用域、作用条件。
只有对《游戏客户端》的《业务功能》，MRCV才发挥最大的价值。业务功能包括核心玩法等深度内容。
《设计模式框架》：并非以底层实现和问题解决为主的Framework，而是指导开发中具体问题的解决方案的Design Method。
MRCV主要对显示层和数据层的设计提出指导性的解决方案。它不代理业务逻辑。
MRCV的唯一目标是提升迭代速度。*简化外层工作并非降低外层工作含金量，反而是对每个人提出了更高要求，要求大家共同完善框架。MRCV绝不只是代码框架，它的作用域覆盖整个游戏开发流程，它倡导职能间互相关心、紧密合作。
MRCV必须依赖《设计》的合理抽象。这包括策划设计开始，到美术效果、资源落地、代码设计的全部内容。
MRCV并非Framework类框架，它是一个提供设计指导的轻度框架，并随项目需求逐渐成长。因此它适用于任意复杂度的项目。
二、简单理解
- 借鉴ECS的显示层设计
- 借鉴MVC的业务逻辑分层
- 借鉴MVVM的视图刷新方法
三、具体设计
ViewEntity(UI)层
- 轻量级，代码量应当极低。
- 模式化，代码框架可自动生成，仅需填充必要逻辑内容。
- 不直接存储数据。
- 不直接执行业务逻辑。
（这是功能铺量开发中需要编写的内容，但不会耗时耗力）
ViewProxy层
- 代理显示层的特定功能需求，抽象和封装显示层的业务逻辑。
- 为实现功能需求，存储相关的必要数据和状态。
- 支撑资源工具链、管理资源数据，负责跨平台兼容。
- 与UnityDOTS天生相合的性质。
（功能开发中仅对这部分内容进行使用，并在必需时扩展）
ViewSystem层
- 统管所有(或关心的)ViewProxy。
- 桥接数据层与显示层，实现数据响应式组件。
- 统管视窗生命周期，负责更全局的逻辑处理。
- 可以与框架外做统一沟通。
（一般功能开发时不关心这层内容，但部分系统需在该层搭建。如：数据响应系统、红点系统）
这层可以与外界沟通，但不是主要沟通发起点。（甚至现在没有这种需求）
LogicManager层
- 负责业务逻辑及相关临时数据。
- 携带相关数据的引用。
- 对框架内负责协调和通信。
- 是对框架外的主要出入口。
（这是功能铺量开发中实现具体业务逻辑的部分）
应在这里点出交互流图。
LogicManager和ViewSystem在设计中是唯二有权与外界沟通的模块，其中以LogicManager为主。
常常为了图方便把对框架外的调用逻辑写在View层，这是可以接受的，但写的越多，代码越难维护。写在DataModel层是不能接受的。
DataModel层
- 仅存储数据。（不包括显示数据等临时数据）
- 声明数据约束，设定数据性质。
- 负责将外部数据转化为我们需要的最优数据结构。（解析）
（这是功能铺量开发中最主要关注并设计的内容，这层设计的优劣决定了功能设计的优劣）
这里不应一笔带过，需细讲数据层设计，以及抽象和继承的原则。（数据层以继承为主！）
DataModeler层
- 统管数据层，负责池管理、性能优化等诸多内容实现。
- 保证数据约束、数据关系、数据安全性和唯一性。
- 实现数据验证等功能。
四、成效与展望
成效
- 流程：在ViewProxy层打通程序、资源和配置，实现解耦(互不依赖)
- 迭代速度：更简单的外层代码编写和工具支持，UI代码需编写内容量降低70%
- 更好的性能：视图中的最小化刷新
展望
- 流程：在ViewProxy层打通程序、资源、配置甚至美术：数据同源
- 迭代速度：更更简单的外层代码编写和工具支持
- 更好的性能：全面的最小化刷新，与UnityDOTS相结合
- 稳定性：数据建模，复杂约束与离/在线验证
- 解决方案：在重度系统中，ViewSystem层的发力点
- ……
五、落地
代码设计倾向
- 数据结构设计是功能编写中最重要的部分，始终保持数据驱动的设计理念。
- 在View层中，倾向于组件而非继承；在Model层中，倾向于继承而非组件。
- View层中应尽量不处理具体业务逻辑和存储业务数据；若有，优先考虑是否可以抽象。
- 在Manager的业务逻辑编写中，需格外关注逻辑入口唯一性。
- 在数据设计中，需格外关注数据唯一性和正确性。