mvc设计模式现在过时了吗_探讨：为什么在游戏开发中不使用MVC？

本篇文章我的观点，部分来源于多年的项目实践，部分源自和以前同事的讨论，以及对一些系列文章和问答的阅读。

正文开始前，先做一些声明，因为这种类型的讨论，必然导致很多反对。我只表明我个人的意见，说一点我的思考实践，以及给出一些我看到的能支持我想法的论据。后续内容中，我可能对mvc或者当前的一些框架和设计方式提出一些批评，并不表明我是百分百坚定我的想法，也不表明我认为自己的想法绝对正确，做法最优。为了不在行文中，反复需要表明我的不坚定，导致文章难以阅读，故在此统一声明，希望不要引起无谓的纷争。

以下文章中，MVC泛指MVC，包括MVVM，MVP等MVC衍生的类似设计模式。

首先，我是用MVC的，在毕业早期开发应用软件类程序，对不同数据的不同展示方式MVC是很好的设计。或者说，一个M（数据），多种V（展示），是应用软件的常见展示方式，很适用MVC。大家在看Design pattern介绍MVC的时候，常用的例子，就是一个数据，即要饼状图展示，又要柱状图展示。

后来，转行做页游，觉得当时的项目，完全没有什么设计，胡乱堆砌，乱成一团，想起了MVC等设计模式，并且，还有很多人推荐的PureMVC，Robotleg等类MVC框架，并使用了依赖注入等模式，学习了demo之后，觉得很好地解决了游戏设计问题。在跳槽后，在新的项目中，已经使用了robotleg，我进去后就很开心，开心地使用。真实地开发一段时间以后，我开始感觉到MVC或者说这类框架的问题（在和同事的讨论中，也得到了牛逼同事很多提点），或者说，是使用者带来的问题：

1，代码繁冗，当你阅读别人的代码，一个很简单的逻辑，被封装了多次，需要在多个代码文件中索引，阅读效率极低。代码文件分散，一些很简单的逻辑，例如按钮点击，都做了多层封装。

2，不太专业的某些程序的惰性，导致他们并不是真正理解MVC或者说这些框架的原理，他们的目标只是，把功能搞出来。他们要么绕过框架，穿插了很多调用，要么整体copy别人的一个功能，去掉逻辑，留下骨架，然后填充自己的逻辑，也不管这个骨架是否适用。这样的人，大大增加了项目的混乱，leader要做到充分的代码review，去除这些问题，在开发进度吃紧，每周都要出版本的情况下，是不可能的。这些快速堆出功能的程序员，反而得到策划等非技术人员的赞赏。而认真处理，把每一块都做好，但是慢一点的程序，反而不受夸奖，这导致了劣币驱逐良币。我相信，除了极少数精英团队，很多团队都有这样的问题。

3，这些设计和框架，被滥用。比如MVC也许适用于UI部分的设计，但是，他是否适用一个战斗模块呢？他是否适用一个剧情模块呢？有些团队，机械地运用某些框架，并不根据需求去思考，认为某个东西是好的，就到处使用。

当一个项目规模增长，人员难以保证精英，积累了大量的需求变更，运营期间，需要快速的迭代。这种繁杂冗余的框架式设计，会导致代码难以维护。有时候，并不是某个框架不够好，更多的是，我们没有仔细理清它的适用范围，也难以保证规范从头到尾的坚定执行。并留下大量过分设计的繁杂代码，一个一百行，几个funtion就能解决的问题，被包装成了多个class，层层调用，写了几大百行，逻辑处处分散。

那么，到底是某个框架，或者设计模式不行，还是我们使用得不够好呢？

我们回到最初，仔细考虑，MVC解决的核心问题是，一个M，多个V，那么，在游戏领域，这样的需求多吗？是强需求吗？我们到底应该根据需求来设计框架，还是应该根据框架来填充需求？一个框架，一套设计，适用不同的游戏，不同的逻辑吗？

我认真地考虑这块问题，发现很多教程，文章，他们介绍MVC，MVVM，介绍各种框架，包括uframe，StrangeIoC等，都缺少了思考和提问：

• 这个框架适用什么需求？解决了什么问题？
• 在什么情况下我该用，什么情况不该用？他带来了什么问题？
• 是否适合我的项目，我的团队？
• 我是应该项目整体使用，还是某些局部的需求使用呢？

等等问题，才是我们该问的关键。

我们游戏领域的技术，特别是游戏的框架，受到了太多应用软件，web开发，app开发的影响，但是，这些模式并不适用我们啊！正式因为web，app这些领域的通用性，需求的固定性（相对游戏开发而言），他们才会诞生出如此多的框架，模式，并且在技术领域，发出了更多的声音。出现了看似高级的设计方式。并且，web，app的项目周期，以及后续的维护周期是很长的，少则三两年，多则十几年，确实必须要谨慎设计。但是，我们游戏，特别是现在手游的生命周期又有多长呢？当需求不同，考虑问题的方式，解决问题的方式，应该做些改变。

想想《代码大全2》开篇说的是什么？隐喻，隐喻的重要性。这是全书的纲领啊，同志们。游戏开发，和web，app开发，能归为同一个隐喻吗？ 那么我们问问自己：

• TDD适用我们游戏前端开发吗？
• WinForm的数据绑定，是适合我们游戏开发的吗？
• 几十个设计模式，有几个能适用我们游戏开发的呢？分别对应什么应用场景呢？
• 用Design pattern的目的，到底是design，还是去解决具体的问题？

当我们去追逐更新的设计，更酷的框架，我们有了解他们解决的问题吗？我们有自己了解过他的原理吗？到底在我们自己的项目中，他能解决什么问题？我们有仔细思考过他在我们游戏开发的整个生命周期，会给我们带来什么吗？

最近，因为守望先锋的一个分享，ECS开始火了起来。有个群里看到说，我们下个项目要上ECS了，问是什么类型，答不知道，但是ECS这种先进框架，肯定要用。我只能说汗~~~

静下心来，我也追求过最新的技术，最新的框架。但是，当我们真心开始做一个项目，去解决一些问题的时候，我们需要审慎。

比如ECS，我觉得云风的说法，是最中肯的:

云风博客截图，地址https://blog.codingnow.com/2017/06/overwatch_ecs.html

最终，我们要回到需求和问题，ECS，核心是为了解决网络同步中预测和预测失效的状态回滚问题。如果你不是需要解决这类问题，你确定需要上ECS？一个回合制游戏，确定需要ECS？UI写法从MVC改ECS？

写到这里，说了那么多批评的话，那么，我认为什么是最好的设计方式呢？

我认为，没有最好的，只有根据需求来的，根据团队能力来的，根据项目进度，经费来的，一切都要“具体问题，具体分析”。这句话，说出来轻松，做起来难，也有可能导致什么都做不好，代码更加混乱。那么，只能根据团队能力来选择一个合适的开发方式，没有最佳。

从MVC开始，说了那么多，太多都是务虚的。但是，我认为务虚是很重要的，思考方式，方法论，都是很重要的。甚至，我们程序员学点哲学，也是大大有益。至少，读读笛卡尔的《谈谈方法》吧。

我们需要经验慢慢积累，也需要慢慢对一些技术名词去媚，没有一招吃遍天。以下，我给出一些文章，也是一些我看到的，和我想法类似的东西，大家可以参看：

• Why are MVC & TDD not employed more in game architecture?
• Is the MVC design pattern used in commercial computer games

从第一篇能衍生出很多链接，都可以参看思考。

最后，我言辞可能略激烈，原因大家请参考前面的声明。希望这篇务虚的思考和讨论，能带来一些不一样的声音。

-------------------------------------------------------------------------------------------

补充：

看了评论区里的一些评论，我觉得，我必须要说明一下：我写这篇的目的，不是要告诉大家，设计不重要，框架不重要。我想明确的是：我们要仔细思考需求，来选择合适的技术方案，而不是用在一个死板地框架里硬套需求。能够审慎地选择合适的设计方案，不盲从跟风。

但是，有些评论走向了另一个不看重设计的极端，情绪式的发泄，我认为是不妥的，更加有害的。本来，做任何一个设计，都需要试错，根据需求的变更重构和改进，这当然需要时间成本，但是，这是我们的重要的个人成长之路，至少说明一个程序是看重自己的代码的，重视自己的工作的。

大环境的问题，老板的问题，或者leader的问题，进度紧的问题，当然是存在的客观因素。但是这些客观因素，不代表我们不能努力把事情做好，不代表我们不需要为自己的成长负责。如果因为客观原因，混日子，随便堆砌代码，是对自己的不负责任吧。

行业开发进度紧，加班多，是一个非常不好的状态，我对此也很不满（之前加班痛苦时，甚至yy要组织个程序工会，汗~~）。但是我相信没有一个人的工作是绝对长时间维持饱和的。我们总有时间聊聊qq，微信，上上网吧，那代表我们总有时间去思考怎么把事情做得更好，只是个人选择而已。

一个好的程序，会考虑当前需求，会预估一些需求的变化，给自己留些余地，多少也会考虑，如果别人接手，是否能理顺这个逻辑，后续变更大了，还会考虑去重构整理。甚至会站在用户，玩家的角度，给策划一些建议。这当然是知易行难的，所以，人和人，才有了区分，同样的工作经验，有的一两年，就能做到很好，能独当一面，有的5,6年后，混成了老油条。

总而言之，我这篇文章，是希望在认真对待工作和技术的情况下，更明智地思考和分析需求，选择合适的设计或者实现方案。

虚无主义地吐槽，总是容易的。努力，总是伴随着困难。