前言

作为一个unity 开放者来说，工程规范是及其重要的，而文件规范又占了一大部分

这文件规范就像一个个柜子一样，你正确放置物品的话下一次找到这个资源就很容易。

不想整理？你多人协作后就知道什么是痛苦了

命名规则

Assets目录中的所有资源文件名（场景、脚本、预设、模型、网格、纹理、材质、精灵、着色器、音频剪辑、视频剪辑）均采用 大驼峰式命名法 ，即每一个单词的首字母都大写。且使用能够描述其功能或意义的英文单词或词组。

文件目录

目录	说明
ABRes	自定义资源目录，用于存放需要动态加载的AB包中的资源。职责类似于Artwork,需要热更新的放入该文件夹并打包.
Artwork	存放美术资源的目录（涵盖动画、模型、材质、Shader、UI、原图等等），最好通过 svn 外链或者 git submodel 的方式引入，同样在上面的目录少了一个策划的目录，其实一般就是一个 csv 目录，一般也是通过 svn 外链或者 git submodel 的方式引入
Editor	编辑器目录，存放扩展编辑器的代码，该代码可调用Unity Editor的API。该目录中的代码不会被打进最终的包内。例如，自定义打包工具的代码就放在此目录中。
External	这个目录主要是放置一些外部的插件 Package，例如腾讯的行为树插件，注：外部的 Package 很多代码结构都比较混乱，特别是美术 Package，无论是程序还是美术 Package，请注意都要自己理解透，在按照自己的项目结构整理进对应的目录，如果是代码，不建议整合进自己的项目
Gizmos	Gizmos绘图相关的资源放这里，绘制的效果不会在Game视图中显示，除非在Game视图中勾选Gizmos。该目录的资源不会被打进最终的包内。
Plugins	插件目录，用于存放第三方SDK库文件，如微信开放平台的SDK。子目录包括Plugins/Android和Plugins/iOS。此外，还可以存放其他第三方库，如HoTween.dll、Zxing.dll、Ionic.Zip.Unity.dll等。
Resources	资源目录，用于存放需要动态加载的资源。该目录下的所有文件都会自动打进包内，并执行资源压缩。资源文件通过Resources.Load接口进行加载。这是一个只读的文件夹，程序运行时只能读不能写。
StreamingAssets	流式资源目录，该目录下的所有文件都会自动打进包内，但不会被压缩。它是一个只读的文件夹，程序运行时只能读不能写。可以使用Application.streamingAssetsPath访问该路径。通常用于存放AssetBundle文件。
Scripts	脚本目录，用于存放C#游戏脚本。注意，如果是编辑器工具类的C#脚本，则放在Editor目录中。
Scenes	场景目录，用于存放场景文件，包括场景的Lighting灯光烘焙数据、Navigation导航数据等。
Shaders	着色器目录，用于存放shader文件。Shader一般是技术美术来写，涉及到一些艺术表现效果。
RawAssets	生肉资源目录（自定义），用于存放未加工的资源，如骨骼、动画、贴图、材质等依赖文件。这些资源会作为熟肉资源（预设）的依赖项。
GameAssets	熟肉资源目录（自定义），用于存放已加工过的资源，如预设。通常会将该目录中的资源打成AssetBundle并放在StreamingAssets目录中。在编辑器环境下，可以使用AssetDatabase.LoadAssetAtPah直接加载该目录中的资源。

在ArtWork下的美术资源文件：

目录	说明
Animations	动画相关的资源文件。
Animators	动画控制器相关的资源文件。
Audios	音频相关的资源文件。
Environment	存放与环境相关的资源文件，如背景、建筑物、地形、天空、树木、水体等。
Effects	存放与特效相关的资源文件，比如粒子系统，摄像头渲染特效，动作特效，技能特效，画面特效等。
Materials	材质相关的资源文件。
Models	模型相关的资源文件。
Prefabs	预制体相关的资源文件。
Sprites	精灵相关的资源文件。
Shaders	着色器相关的资源文件。
Textures	纹理相关的资源文件。
UI	存放与游戏界面（UI）相关的资源文件，如按钮、图标、输入框、列表等。

Scripts文件夹的规范

MVC

Scripts 作为代码的主体维护的文件夹，其实对它的分类非常的重要

可以使用MVC或者ECS的格式来的.

根据[QFrameWork](QFramework 简介 Intro — QFramework 1.0.60 文档)的定义来说(我把IController 分为了VIew 和Controller层)

分为五层

视图层: View
控制层：IController
系统层：ISystem
数据层：IModel
工具层：IUtility

基础架构

层(中)	层(英)	接口	职责	规则
表现层	ViewController 层	IController接口	负责接收输入和状态变化时的表现，一般情况下，MonoBehaviour 均为表现层	可以获取 System、Model 可以发送 Command、Query 可以监听 Event
系统层	System层	ISystem接口	帮助IController承担一部分逻辑，在多个表现层共享的逻辑，比如计时系统、商城系统、成就系统等	可以获取 System、Model 可以监听Event 可以发送Event
数据层	Model层	IModel接口	负责数据的定义、数据的增删查改方法的提供	可以获取 Utility 可以发送 Event
工具层	Utility层	IUtility接口	负责提供基础设施，比如存储方法、序列化方法、网络连接方法、蓝牙方法、SDK、框架继承等。	啥都干不了，可以集成第三方库，或者封装API

通讯	职责	规则
Command	命令，负责数据的增删改。	可以获取 System、Model 可以发送 Event、Command
Query	查询、负责数据的查询	可以获取 System、Model 可以发送 Query

通用规则：
- IController 更改 ISystem、IModel 的状态必须用Command
- ISystem、IModel 状态发生变更后通知 IController 必须用事件或BindableProperty
- IController可以获取ISystem、IModel对象来进行数据查询
- ICommand、IQuery 不能有状态,
- 上层可以直接获取下层，下层不能获取上层对象
- 下层向上层通信用事件
- 上层向下层通信用方法调用（只是做查询，状态变更用 Command），IController 的交互逻辑为特别情况，只能用 Command

通用规则是理想状态下的一套规则，但是落实的实际项目，很有可能需要对以上规则做一些修改。