浅谈unity3d中使用MVC框架模式

MVC框架模式，相信很多人都不会陌生，数据-控制-显示分离的工作方式或者叫做代码结构会使软件（游戏）的结构清晰化，逻辑更明了。但由于MVC框架模式各部件都可以与彼此进行沟通，造成了很多新人在使用MVC的时候消息满天飞，解耦没成，耦合度更高了。我建议在使用MVC的时候，制定策略，让消息单向化，不要双向或形成网状。

好了，我们下面讨论一下Unity3D是否可以使用MVC，如何使用会比较好?（方法有很多种，这里我只写我比较认同的一种）

既然我写了有我比较认同的方式，那么在Unity3D中使用MVC至少我个人持赞成态度，任何东西没有好与坏，只有适用不适用。

Unity3D本身的MonoBehavior脚本是一个重大突破，达到了组件式开发的目的。但是我依然要说，东西虽好，不能乱搞。我个人认为：组件式开发是好的方式，但组件本身却是依靠传统的编程方式建立的，所以除开组件最适用的地方外，强制使用组件进行开发是违和的。MonoBehavior脚本，我们可以将它理解为界面层与界面直接沟通的上层脚本，在他底部的控制、逻辑、数据等有必要用MonoBehavior脚本么？至少我认为是不必要的（为什么要用用不到的东西管理数据和逻辑呢?）。底部的控制、逻辑用什么实现好呢？方式很多，至少MVC框架模式是一个选择。而在使用MVC时，我个人认为模块内小规模使用MVC更合理，模块内的数据、控制、界面关系比较紧密，模块之间提供合理的接口进行跳转即可（不排除模块间消息沟通）。而模块内使用MVC时，也要遵循消息流向单向化，即：接收方永不发送消息，发送方永不接收消息。有人说不太可能，我给大家提供一个模型供参考：

1.      定义M只提供两种函数接口：操作、获取数据；并可以发送更新消息

2.      定义V只接收消息并控制界面显示、跳转、效果等

注：界面（暂且称之为UI）自身处理界面点击等操作直接调用M层进行处理或内部消化或发送给V进行控制跳转

3.      定义C实现必要逻辑（非界面自身逻辑）

我们来看以上模型：

a. 用户点击->UI响应控制->调用M更改数据->发送更新界面消息->V接收消息->更新界面

b. 用户点击->UI响应控制->发送界面跳转消息->V接收消息->更新界面

c. 用户点击->UI响应控制->UI自消化

其实，一般的界面模块，用以上的模型就足够了。但有些模块比较复杂，需要不断的与数据和界面交互，这时候C才有意义。

以上方式，纯属个人比较认可的方式，在实际开发中，每个人都会有自己的观点存在，但一个项目只能用统一的方式才方便沟通、交接、扩展…