8

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

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

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

我考虑过让 GUI 成为主要模块，并为工具栏例程、菜单例程等设置单独的模块，但那时我相信我将失去 OOP 的大部分好处并最终得到一个一切都引用一切的场景.

我应该只处理一个很长的中央模块，还是有更好的方式来构建项目，这样我就不必过多地依赖类浏览器？

编辑我

好的，关于所有 MVC 的东西都采取了这一点。我的代码中确实有一个粗略的 MVC 近似值，但不可否认，通过进一步分离模型和控制器，我可能会获得一些进展。但是，我正在阅读 python-gtkmvc 的文档（顺便说一句，这是一个很棒的发现，感谢您参考它），我的印象是它并不能解决我的问题，而只是形式化它。我的应用程序是一个单一的空地文件，通常是一个窗口。因此，无论我多么严格地定义模块的 MVC 角色，我仍然会让一个控制器模块完成大部分工作，这几乎就是我现在所拥有的。诚然，我对正确的 MVC 实现有点模糊，我会继续研究，但事实并非如此

我应该为窗口的不同部分（工具栏、菜单等）考虑单独的控制器/视图对吗？也许这就是我在这里所缺少的。似乎这就是 S. Lott 在他的第二个要点中所指的内容。

感谢您到目前为止的回复。

4

6 回答 6

7

In the project Wader we use python gtkmvc, that makes much easier to apply the MVC patterns when using pygtk and glade, you can see the file organization of our project in the svn repository:

wader/
  cli/
  common/
  contrib/
  gtk/
    controllers/
    models/
    views/
  test/
  utils/
于 2008-10-19T07:39:33.587 回答
2

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

于 2008-10-19T06:15:00.607 回答
2

"holds the primary application class (most functional routines)"

As in singular -- one class?

I'm not surprised that the One Class Does Everything design isn't working. It might not be what I'd call object-oriented. It doesn't sound like it follows the typical MVC design pattern if your functionality is piling up in a single class.

What's in this massive class? I suggest that you can probably refactor this into pieces. You have two candidate dimensions for refactoring your application class -- if, indeed, I've guessed right that you've put everything into a single class.

  1. Before doing anything else, refactor into components that parallel the Real World Entities. It's not clear what's in your "state.py" -- wether this is a proper model of real-world entities, or just mappings between persistent storage and some murky data structure in the application. Most likely you'd move processing out of your application and into your model (possibly state.py, possibly a new module that is a proper model.)

    Break your model into pieces. It will help organize the control and view elements. The most common MVC mistake is to put too much in control and nothing in the model.

  2. Later, once your model is doing most of the work, you can look at refactor into components that parallel the GUI presentation. Various top-level frames, for example, should probably have separate cotrol objects. It's not clear what's in "GUI.py" -- this might be a proper view. What appears to be missing is a Control component.

于 2008-10-19T12:53:42.110 回答
2

Sorry to answer so late. Kiwi seems to me a far better solution than gtkmvc. It is my first dependency for any pygtk project.

于 2008-10-31T01:31:40.560 回答
0

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

myapp/
  application/
  gui/
  command/
  state/

Where each directory has its own __init__.py. You can have a look at any python app or even standard library modules for examples.

于 2008-10-19T06:41:46.667 回答
0

So having not heard back regarding my edit to the original question, I have done some more research and the conclusion I seem to be coming to is that yes, I should break the interface out into several views, each with its own controller. Python-gtkmvc provides the ability to this by providing a glade_top_widget_name parameter to the View constructor. This all seems to make a good deal of sense although it is going to require a large refactoring of my existing codebase which I may or may not be willing to undertake in the near-term (I know, I know, I should.) Moreover, I'm left to wonder whether should just have a single Model object (my application is fairly simple--no more than twenty-five state vars) or if I should break it out into multiple models and have to deal with controllers observing multiple models and chaining notifications across them. (Again, I know I really should do the latter.) If anyone has any further insight, I still don't really feel like I've gotten an answer to the original question, although I have a direction to head in now.

(Moreover it seems like their ought to be other architectural choices at hand, given that up until now I had not seen a single Python application coded in the MVC style, but then again many Python applications tend to have the exact problem I've described above.)

于 2008-10-20T20:15:32.567 回答