ECS？

• 真正的ECS属于是entity-component-system
• 组件里面只有数据没有方法，system里面是针对组件的方法，system通过查找只需要关注自己想关注的组件集合就可以。
• 但是ET框架的代码在组件里面写满了方法，有数据又有方法的组件，随时可拆卸，像什么？没错
• 是Unity的组件模式
• 看这个资源组件
  
• 而这种组件本质上相当于我们经常用的单例Manager，只不过他是属于系统层面的服务，所以全部挂载到Game这个实体上面了
• 所以ET框架本身是一个杂糅的东西，他把Unity的组件模式和ECS式的东西混在了一起。
• 真正的ECS框架可以看这个ECS框架
• 他是为了用ECS而去用ECS，但本质上还是OOP那一套。
  
• 另外，在我看来ECS其实是对MVC里面的Model业务模型进行了拆分，但是对于VC来说，该怎么写还是怎么写。
• 当然有失偏颇，我可能看一些ECS的demo源码会有更深入理解

消息处理

• 在消息处理这方面
• 它的逻辑是这样的，在点击进入地图的按钮之后他会发送一个消息到服务器，服务器会发送一个玩家ID回来
• 这个玩家ID就是客户端的唯一标识
• 在收到服务器的回复消息时，再发送一个创建Unit的内部消息
• 这个内部消息的处理者会创建这个Unit并进行广播，为什么要广播，不是很懂？为什么不用事件而要用内部消息也很奇怪？
• 在创建Unit的时候在他身上挂载了寻路组件和移动组件。
• 而游戏场景里面有一个OperaCompoent，这个组件会实时监听按键的点击并且将点击的位置发送给服务器，服务器再传送回客户端
• 【这边也挺奇怪的，】
• 客户端这边接收ClickMapActor消息后解析位置，调用unit的Path组件进行移动。大体流程就是这样。
• 向服务器发送进入地图
  
• 接收服务器的返回消息后发送内部的创建单位消息
  
• 内部收到后开始创建单位并添加一系列组件
  
• opera组件监听鼠标点击事件并向服务器发送click位置消息
  
• ==在接收消息的处理函数里面进行处理
  
• 但其实这样很不连贯，我发送一个消息，应该await等待获得消息，然后再做处理，这样就弄的很分散不够集中

事件处理

• ET的所有逻辑全部用事件来处理了
• 这带来一个坏处，就是没办法高内聚。
• 本来属于一个业务模型里面的逻辑，通过事件分散到了两到三个脚本里面。增加了阅读难度和上下连贯性。
• 单纯举例来说，游戏初始化后发送了InitScenFinish事件。
• UI处理模块接收到事件创建UI物体并显示
• 在各个UI单独的组件比如LoginCom和LobbyCom里面进行UI逻辑撰写即并绑定事件
• 他把本属于Model层的代码全部写进了静态类Helper里面来调用。
• 也就是说View层直接调用了Model层代码。其实这样就强耦合了。
• 直接调用MapHelper
• 直接调用LoginHelper
  - 它的UI处理也很蹩脚，登录界面属于是LoginState里面，常规来说只需要这样,而我们只需要切换到EnterMapState的时候调用对应接口就行了。这样还上下文明显且连贯

class LoginState:State{
	
	void OnEnter(){
		UI.Show()
	}
	void OnLeave(){
		UI.Hide()
	}

}

• 但是在它的代码中，在发送登录完成消息后是这样的
  
• 因为他要关闭Login的UI，然后显示Lobby的UI
• 但其实Login的加载和卸载明明放在一个脚本会更好