如何连贯地组织 PyGTK 桌面应用程序的模块？

StackOverflow https://stackoverflow.com/questions/216093

题

我正在 PyGTK 中开发桌面应用程序，似乎遇到了文件组织的一些限制。到目前为止，我已经这样构建了我的项目：

  • application.py - 保存主要应用程序类（大多数功能例程）
  • gui.py - 拥有松散耦合的 GTK gui 实现。处理信号回调等。
  • command.py - 保存不依赖于应用程序类中的数据的命令行自动化功能
  • state.py - 保存状态数据持久化类

到目前为止，效果相当好，但此时 application.py 开始变得相当长。我查看了许多其他 PyGTK 应用程序，它们似乎也有类似的结构问题。在某个时刻，主模块开始变得很长，并且没有明显的方法可以在不牺牲清晰度和面向对象的情况下将代码分解为更窄的模块。

我曾考虑过将 GUI 作为主要模块，并为工具栏例程、菜单例程等提供单独的模块，但到那时我相信我将失去 OOP 的大部分好处，并最终得到一切引用一切的场景。

我应该只处理一个很长的中央模块，还是有更好的方法来构建项目，以便我不必如此依赖类浏览器？

编辑我

好的，以上就是关于所有 MVC 内容的观点。我的代码中确实有 MVC 的粗略近似，但不可否认，通过进一步分离模型和控制器，我可能会获得一些进展。然而，我正在阅读 python-gtkmvc 的文档（顺便说一下，这是一个很棒的发现，感谢您引用它），我的印象是它不会解决我的问题，而只是形式化它。我的应用程序是一个单一的林间空地文件，通常是一个单一的窗口。因此，无论我如何严格地定义模块的 MVC 角色，我仍然会让一个控制器模块完成大部分工作，这几乎就是我现在所拥有的。诚然，我对正确的 MVC 实现有点模糊，我将继续研究，但在我看来，这个架构不会从我的主文件中获取更多内容，它只是重命名它文件到controller.py。

我是否应该考虑为窗口的不同部分（工具栏、菜单等）使用单独的控制器/视图对？也许这就是我在这里所缺少的。看来S就是这个样子的。洛特在他的第二个要点中提到了这一点。

感谢到目前为止的回复。

有帮助吗？

解决方案

在项目中 涉水者 我们用 蟒蛇gtkmvc, ，这使得在使用 pygtk 和 Glade 时应用 MVC 模式变得更加容易，您可以在 svn 存储库:

wader/
  cli/
  common/
  contrib/
  gtk/
    controllers/
    models/
    views/
  test/
  utils/

其他提示

这可能与 PyGTK 无关，而是一般的代码组织问题。您可能会从应用一些 MVC（模型-视图-控制器）设计模式中受益。看 设计模式, ， 例如。

“持有主要应用程序类（大多数功能例程）”

如单数形式——一类？

我并不感到惊讶的是 一堂课搞定一切 设计不起作用。这可能不是我所说的面向对象。如果您的功能堆积在单个类中，那么听起来它并不遵循典型的 MVC 设计模式。

这个庞大的班级里有什么？我建议你可以将其重构为碎片。您有两个候选维度来重构您的应用程序类 - 如果我确实猜对了，您已将所有内容放入一个类中。

  1. 在做任何其他事情之前，请重构为与现实世界实体平行的组件。目前尚不清楚“state.py”中的内容 - 这是现实世界实体的正确模型，还是只是持久存储与应用程序中某些模糊数据结构之间的映射。您很可能会将处理从应用程序移出并转移到模型中（可能是 state.py，可能是一个合适模型的新模块。）

    将你的模型分解成碎片。它将有助于组织控制和视图元素。最常见的 MVC 错误是在控制中投入太多，而在模型中却没有投入任何内容。

  2. 稍后，一旦您的模型完成了大部分工作，您就可以考虑重构为与 GUI 演示并行的组件。例如，各种顶级框架可能应该有单独的控制对象。目前尚不清楚“GUI.py”中的内容 - 这可能是一个正确的视图。似乎缺少的是控制组件。

抱歉这么晚才回复。 猕猴桃 在我看来，这是一个比 gtkmvc 更好的解决方案。这是我对任何 pygtk 项目的第一个依赖项。

Python 2.6 支持 显式相对导入, ，这使得使用包比以前的版本更加容易。我建议您考虑将应用程序分解为包内更小的模块。您可以这样组织您的应用程序：

myapp/
  application/
  gui/
  command/
  state/

每个目录都有自己的目录 __init__.py. 。您可以查看任何 python 应用程序甚至标准库模块作为示例。

因此，在没有收到关于我对原始问题的编辑的回复后，我做了一些更多的研究，我似乎得出的结论是 是的, ，我应该将界面分成几个视图，每个视图都有自己的控制器。Python-gtkmvc 通过提供一个 glade_top_widget_name View 构造函数的参数。这一切似乎都很有意义，尽管它需要对我现有的代码库进行大量重构，我可能愿意也可能不愿意在短期内进行（我知道，我知道，我 应该。）此外，我想知道是否应该只有一个模型对象（我的应用程序相当简单——不超过二十五个状态变量），或者我是否应该将其分解为多个模型并必须处理控制器观察多个模型并在它们之间链接通知。（再说一遍，我知道我真的 应该 做后者。）如果有人有任何进一步的见解，我仍然不觉得我已经得到了最初问题的答案，尽管我现在有一个前进的方向。

（此外，鉴于到目前为止我还没有看到过以 MVC 风格编码的 Python 应用程序，因此它们似乎应该是其他架构选择，但许多 Python 应用程序往往会遇到我所描述的确切问题多于。）

许可以下： CC-BY-SA 和 归因
不隶属于 StackOverflow
scroll top