Question

我正在使用PyGTK中的桌面应用程序，似乎遇到了我的文件组织的一些限制。到目前为止，我以这种方式构建了我的项目：

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

到目前为止，这已经相当不错，但此时application.py开始变得相当长。我查看了许多其他PyGTK应用程序，它们似乎有类似的结构问题。在某一点上，主模块开始变得非常长，并且没有明显的方法将代码分解成更窄的模块而不牺牲清晰度和面向对象。

我已经考虑过将GUI作为主要模块，并为工具栏例程，菜单例程等提供单独的模块，但是在那一点上我相信我将失去OOP的大部分好处并最终得到一切 - 参考 - 一切情况。

我应该只处理一个非常长的中央模块，还是有更好的方法来构建项目，这样我就不必那么依赖类浏览器了？

编辑我

好的，关于所有MVC的内容都是如此。我的代码中确实有一个粗略的MVC近似值，但不可否认，我可能通过进一步隔离模型和控制器来获得一些里程。但是，我正在阅读python-gtkmvc的文档（顺便说一句，这是一个很好的发现，谢谢你参考它），我的印象是它不会解决我的问题，只是将它正式化。我的应用程序是单个glade文件，通常是单个窗口。因此无论我如何紧密地定义模块的MVC角色，我仍然会有一个控制器模块执行大部分操作，这正是我现在所拥有的。不可否认，我对适当的MVC实现有点模糊，我将继续研究，但它并不认为我这样的体系结构会从我的主文件中获取更多东西，它只是将重命名为file to controller.py。

我是否应该为窗口的单独部分（工具栏，菜单等）考虑单独的控制器/视图对？也许这就是我在这里所缺少的。看来这就是S. Lott在他的第二个要点中提到的。

感谢到目前为止的回复。

Answer 1

在项目Wader中我们使用python gtkmvc，这使得在使用pygtk和glade时更容易应用MVC模式，您可以在svn repository中看到我们项目的文件组织：

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

Answer 2

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

Answer 3

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

如同单数 - 一类？

我很惊讶 One Class Does Everything 设计不起作用。它可能不是我所谓的面向对象。如果你的功能集中在一个类中，它听起来不像典型的MVC设计模式。

这个庞大的课程里有什么？我建议你可以把它重构成碎片。你有两个候选维度来重构你的应用程序类 - 如果我确实猜对了你把所有内容都放在一个类中。

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

将模型分解成碎片。它将有助于组织控件和视图元素。最常见的MVC错误是控制过多而模型中没有任何内容。
稍后，一旦您的模型完成大部分工作，您就可以将重构视为与GUI表示并行的组件。例如，各种顶级框架应该具有单独的cotrol对象。目前尚不清楚“GUI.py”中的内容 - 这可能是一个正确的观点。似乎缺少的是控制组件。

Answer 4

很抱歉这么晚回答。 Kiwi在我看来比gtkmvc更好的解决方案。这是我对任何pygtk项目的第一个依赖。

Answer 5

Python 2.6支持explicit relative imports，这使得使用包比以前的版本更容易。我建议你考虑将你的应用程序分解成一个包中的小模块。您可以像这样组织您的应用程序：

myapp/
  application/
  gui/
  command/
  state/

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

Answer 6

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

（而且看起来他们应该是他们手头的其他架构选择，因为到目前为止我还没有看到以MVC风格编码的单个Python应用程序，但是后来许多Python应用程序往往会遇到确切的问题我如上所述。）

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

6 个答案: