PyQt и MVC-паттерн

Первое, что вам следует сделать, это использовать конструктор Qt4 для разработки графического интерфейса пользователя и использовать pyuic4 для создания графического интерфейса пользователя Python. Это будет ваше мнение, вы НИКОГДА не редактируете эти файлы python вручную. Всегда вносите изменения с помощью конструктора, это гарантирует, что ваше представление отделено от вашей модели и элемента управления.

Для элемента управления создайте центральный класс, который наследуется от вашего базового виджета графического интерфейса, такого как QMainWindow. Затем этот объект будет содержать пользовательский интерфейс, который является вашим объектом представления, который вы только что сгенерировали.

вот пример из учебника

ОБНОВЛЕНИЕ 2013: Вот более свежие учебники ) на PyQt и модели MVC PyQt MVC Tutorial Series

import sys
from PyQt4 import QtCore, QtGui
from edytor import Ui_notepad

class StartQT4(QtGui.QMainWindow):
    def __init__(self, parent=None):
        QtGui.QWidget.__init__(self, parent)
        self.ui = Ui_notepad()
        self.ui.setupUi(self)


if __name__ == "__main__":
    app = QtGui.QApplication(sys.argv)
    myapp = StartQT4()
    myapp.show()
    sys.exit(app.exec_())

Ключевым моментом в приведенном выше примере является то, что контроллер содержит пользовательский интерфейс и не наследует его напрямую. Контроллер будет отвечать за управление подключениями сигнальных слотов для вашего графического интерфейса и предоставление интерфейса для вашей модели данных.

Чтобы описать часть модели, нам нужен пример, предположим, что ваш проект заключается в создании базы данных коллекции фильмов. Модель будет включать внутренние объекты, представляющие отдельные фильмы, а также объекты, представляющие списки фильмов. Вы контролируете, берете данные, введенные из представления, и улавливаете сигналы, а затем проверяете их, прежде чем запрашивать обновление модели. Эта часть имеет решающее значение, контроллер не должен напрямую обращаться к модели, если это вообще возможно, он должен запрашивать доступ у модели к себе.

Вот небольшой пример этого взаимодействия (не проверено, могут быть некоторые опечатки):

class Movie():
    def __init__(self,title=None,year=None,genre=None):
        self.title=title
        self.year=year
        self.genre=genre
    def update(self,title=None,year=None,genre=None):
        self.title=title
        self.year=year
        self.genre=genre
    def to_xml(self,title=None,date=None,genre=None):
        pass #not implementing this for an example!

#when the controller tries to update it should use update function
movie1.update("Manos Hands Of Fate",1966,"Awesome")
#don't set by direct access, your controller shouldn't get that deep
movie1.title="Bad Idea" #do not want!

В MVC также важно централизовать доступ, например, пользователь может изменить заголовок, дважды щелкнув его на экране, или щелкните "Изменить" рядом с полем заголовка, оба этих интерфейсов должны в конечном итоге использовать один и тот же метод для изменения. Я не имею в виду, что каждый из них вызывает movie.update_title (title). Я имею в виду, что оба сигнала должны использовать один и тот же метод в контроллере.

Постарайтесь, насколько это возможно, сделать все отношения между представлением и контроллером равными 1. Это означает, что у вас есть 5 способов изменить что-то в графическом интерфейсе, есть 1 метод в контроллере, чтобы справиться с этим. Если не все слоты совместимы, создайте методы для каждого из методов, которые затем вызывают один единственный метод. Если вы решите проблему 5 раз для 5 стилей представления, тогда действительно нет причин отделять представление от элемента управления. Кроме того, поскольку теперь у вас есть только один способ сделать что-то в контроллере, у вас есть хорошие отношения 1: 1 между элементом управления и моделью.

Что касается того, что ваша модель полностью отделена от Qt, это не совсем необходимо и может фактически усложняют тебе жизнь. Использование таких вещей, как QStrings, в вашей модели может быть удобным, и если в другом приложении вы не хотите накладных расходов на Gui, а хотите, чтобы модели просто импортировали только QtCore. Надеюсь, это поможет!

Что касается того, что ваша модель полностью отделена от Qt, в этом нет необходимости и может действительно усложнить вам жизнь. Использование таких вещей, как QStrings, в вашей модели может быть удобным, и если в другом приложении вы не хотите накладных расходов на Gui, а хотите, чтобы модели просто импортировали только QtCore. Надеюсь, это поможет!

Что касается того, что ваша модель полностью отделена от Qt, в этом нет необходимости и может действительно усложнить вам жизнь. Использование таких вещей, как QStrings, в вашей модели может быть удобным, и если в другом приложении вы не хотите накладных расходов на Gui, а хотите, чтобы модели просто импортировали только QtCore. Надеюсь, это поможет!

Да, PyQt использует концепцию Модель / Представление (официально без части «Контроллер»), но может быть у вас несколько искаженная картина, что это означает в PyQt.

Есть два части:

1. Модели, подклассы соответствующих базовых классов абстрактных моделей PyQt ( QAbstractItemModel , QAbstractTableModel , QAbstractListModel и т. д.). Эти модели могут напрямую взаимодействовать с вашими источниками данных (файлы, базы данных) или проксировать ваши собственные PyQt-агностические модели, которые были написаны ранее.
2. Представления, которые реализованы в библиотеке Qt и часто не требуют каких-либо модификаций (примеры: QTreeView , QTableView и другие). Даже некоторые более простые элементы управления, такие как QComboBox , могут действовать как представление для модели PyQt.