Чтобы дополнить сказанное выше @eyllanesc и еще немного абстрагировать его, я использовал модель MVC для обработки практически всего, что связано с представлением информации пользователю. Таким образом, мой тип MVC также включает в себя некоторые другие модели, которые были впоследствии получены из MVC, и просто смотрите на все это как на разные вкусы MVC, иначе говоря, если его мороженое - мороженое, независимо от того, какие ароматизаторы вы добавили в него.
Во-первых, он был в основном разработан для обработки подключения к базе данных, при этом Модель - это база данных, а View - это графический интерфейс, а Controller - промежуточный уровень, который обрабатывал поток из базы данных в графический интерфейс и из графического интерфейса в базу данных. Однако в моей версии промежуточный уровень стал рабочей лошадкой процесса, поскольку он обрабатывает всю проверку данных, а также применяет любую бизнес-логику, которую необходимо применить к данным, независимо от того, в каком направлении они передаются.
После всего сказанного мы можем сделать шаг назад и посмотреть на приложение Python / PyQt следующим образом:
Модель = Back-End для управления данными, их хранения и / или производства (язык данных - SQL, C и т. Д.)
Контроллер = Среднего уровня обрабатывает проверку данных и применение большинства бизнес-правил Примечание: как я уже говорил выше, я немного отклоняюсь от традиционной версии в том, что я смещаю правила проверки и бизнес-правила в этот раздел, и я делаю это, потому что это означает, что данные затем просто становятся данными, и я могу применить это к вещам, которые не смогут реализовать проверку или правила, такие как последовательные порты низкого уровня и тому подобное. Конечно, если серверная часть является базой данных, в ней могут быть реализованы некоторые правила для данных, которые могут быть аналогичны бизнес-правилам, но в этом варианте они должны быть сведены к минимуму и больше касаться распространения данных и тому подобного. (Только Python)
View = GUI Front-End обрабатывает представление данных пользователю. Обратите внимание, что иногда здесь может происходить некоторая более базовая проверка данных, например, если она только числовая, убедитесь, что она только числовая. (Python / PyQt в основном последний)
Каждый из этих объектов должен быть создан таким образом, чтобы он был в значительной степени независим от другого, а интерфейс полностью отделен от интерфейса. Это означает, что если бы я хотел заменить Средний уровень, я должен был бы сделать это почти без проблем и без необходимости вносить изменения во Front-End или Back-End, и то же самое касается и Front-End, и Back. - Если я заменил их чем-то другим и установил те же связи со средним уровнем, что и раньше, то больше ничего не должно быть затронуто. Конечно, это не всегда происходит, потому что иногда есть изменения, которые затрагивают все 3 уровня, но тогда они все равно могут быть выполнены независимо, все, что должно быть согласовано, это то, что отправляется / принимается из графического интерфейса пользователя и серверной части и / или Средний уровень.
В Front-End это может быть реализовано во время кодирования, не устанавливая соединение при выполнении front-end, вы просто вызываете функцию-заполнитель (которая в конечном итоге будет заменена на промежуточный уровень), и вся эта функция делает это поставка данных, которые будут (или должны) поступить из среднего уровня. Со стороны GUI вас не волнует, как эти данные оказались в том формате, в котором они есть, и все, что вам нужно знать, это то, как они будут предоставлены. То же самое касается отправки данных, которые возвращают данные, просто создайте фиктивную функцию для внешнего интерфейса, который имитирует ситуацию. Таким образом, вы сосредоточены на том, чтобы просто представлять данные пользователю и получать ввод от пользователя, и это все, и помните, прежде всего, K.I.S.S. это - (Держите это Простым и Умным)