我正在使用PyGTK中的桌面应用程序,似乎遇到了我的文件组织的一些限制.到目前为止,我以这种方式构建了我的项目:
application.py - 保存主应用程序类(大多数功能例程)
gui.py - 保持松散耦合的GTK gui实现.处理信号回调等
command.py - 保存命令行自动化功能,不依赖于应用程序类中的数据
state.py - 保存状态数据持久性类
到目前为止,这已经相当不错了,但是此时application.py开始变得相当长.我查看了许多其他PyGTK应用程序,它们似乎有类似的结构问题.在某一点上,主模块开始变得非常长并且没有明显的方法将代码分解成更窄的模块而不牺牲清晰度和面向对象.
我已经考虑过将GUI作为主要模块,并为工具栏例程,菜单例程等提供单独的模块,但在那时我相信我将失去OOP的大部分好处并最终得到一切 - 引用 - 所有方案.
我应该只处理一个非常长的中央模块,还是有更好的方法来构建项目,这样我就不必那么依赖类浏览器了?
编辑我
好的,关于所有MVC的东西都是如此.我的代码中确实有一个粗略的MVC近似值,但不可否认,我可能通过进一步隔离模型和控制器来获得一些里程.但是,我正在阅读python-gtkmvc的文档(顺便说一句,这是一个很棒的发现,谢谢你引用它),我的印象是它不会解决我的问题,只需将其正式化即可.我的应用程序是单个glade文件,通常是单个窗口.因此无论我如何紧密地定义模块的MVC角色,我仍然会有一个控制器模块执行大部分操作,这正是我现在所拥有的.不可否认,我在适当的MVC实施上有点模糊,我将继续研究,但它没有
我应该考虑单独的控制器/视图对用于窗口的单独部分(工具栏,菜单等)吗?也许这就是我在这里所缺少的.似乎这就是S. Lott在他的第二个要点中提到的.
感谢到目前为止的回复.
在项目Wader中我们使用python gtkmvc,这使得在使用pygtk和glade时更容易应用MVC模式,您可以在svn存储库中看到我们项目的文件组织:
wader/ cli/ common/ contrib/ gtk/ controllers/ models/ views/ test/ utils/