Qt 项目中的View、Controller

2019-11-05

  我发现，一些Qt项目中，开发者因为Qt的框架提供了很好的解耦方式，便不再关注controller，把widget class 当作controller。这实在是不应该。在这样的代码基础上进行下去，就会发现所有的东西都逐渐放在了widget上。超大的cpp文件，ui、逻辑、数据库操作，混杂，不可直视。在这里，我们假设系统比较简单，MVC中Model包含了数据库访问（DAO)，Controller包含业务层（如复杂业务算法或流程）。

  我在之前的文章中提过：Qt本身弱化了Controller 概念，把Controller和View 放在一起了。这是合理的，因为signal/slot机制提供了强大的解耦能力。但是，这绝不应该是鼓励我们不重视独立的controller。其一，没有单独的controller，也会导致View包含了过多的业务限制。如果别的业务想要复用View，就会发现难以做到。其二，view包含了太多的东西，导致代码混乱，难以维护。

  过分剥离View与Controller，就会走向另外一种极端。例如在桌面端程序中模仿Web项目中的View/Controller。要知道，web业务比多数桌面端的业务规则是要简单的。Web中的编程范式更像是函数式编程，注重数据的流向。但是，我们是难以看到函数式语言写桌面端项目的，天然不适合。桌面端的View/Controller有着更强的联系，一个View导致的Model层的变动，会牵连导致不少View变动。

  合理的做法是，基本上，一个页面就会需要对应一个controller，特别是直接涉及到操作网络或者数据库的 页面。因为Qt 天然的让view承担了部分的c