Я концептуально намагаюся зрозуміти, чи варто це робити:
item = Model()
screen = View()
brain = Controller(item, screen)
або це ..
brain = Controller()
item = Model(brain)
screen = View(brain)
або це ..
class Controller():
def __init__(self):
item = Model(self)
screen = View(self)
чи щось інше цілком?
Відповіді:
Для мене перший варіант має сенс. Завдання Контролера полягає в координації між видом і моделлю. З цієї точки зору має сенс для контролера бути таким, який контролює посилання на вигляд і модель.
Насправді ви не можете мати контролер без моделі та перегляду, однак має набагато більше сенсу просто мати перегляд або просто мати модель (наприклад, при тестуванні одиниць). Ось чому ви хочете передати ці залежності в Контролер, а не в інші два.
ModelІ Viewнезалежні один від одного.
Не думайте про це Controllerяк про мізки структури MVC. Подумайте про це як про диспетчера, який обробляє запити браузера і пересилає їх до Model. Потім він бере дані з Modelпакета та пакує їх у вигляді шаблону , а потім надсилає їх до а View.
ModelЄ мозок в структурі MVC, і це, де ви повинні покласти ваші бізнес - правила. Правила ведення бізнесу є загальними для кількох контролерів . Таким чином, контролер документів і контролер звітів можуть використовувати і модель користувача, щоб побачити, хто має доступ до цих речей. Ви б не хотіли повторювати ці правила в обох контролерах.
ViewСлід використовувати шаблон HTML , щоб представити дані певним чином без джерела даних. Вона не повинна бути тісно пов'язана зі схемою вашої бази даних. Для того, щоб показати заголовок документа, ви мали б представити вигляд вмісту змінної шаблону, яка називається document_title, і лише те, хто Controllerзнає, як ця змінна була встановлена, і лише Modelзнає, чому цей документ має цей заголовок.
MVC спочатку був визначений для полегшення програмування настільних додатків. Перегляд передплачував події моделі, оновлюючи презентацію, коли модель змінювалася. Контролер просто переводив події користувальницького інтерфейсу (наприклад, натискання кнопки) на дзвінки до моделі. Тож контролер і вигляд залежали від моделі, але були незалежними один від одного. Модель не залежала від обох. Це дозволило декільком переглядачам і контролерам працювати над однією моделлю.
Дещо інша архітектура "MVC", що використовується для веб-додатків 1.0 (оновлення повної сторінки, відсутність AJAX). Веб-запит відправляється контролеру. Контролер якимось чином змінює стан моделі, після чого надсилає одну або кілька моделей для надання видом. Контролер і вигляд залежать від моделі, але контролер також залежить від виду.
За допомогою веб-додатків 2.0 ми повертаємося до класичної архітектури MVC на стороні клієнта . Модель, перегляд та контролер розташовані на стороні клієнта як об'єкти Javascript. Контролер переводить події користувача на дії моделі. Дії моделі можуть або не можуть спричинити запит AJAX до сервера. Знову-таки, перегляд підписується на моделювання подій та оновлення презентації відповідно.
Перегляд повинен передплатити зміни в моделі. Існує широта багатства підписок, оскільки вони можуть бути детальними (покажіть мені зміни в інвентарі для цього конкретного товару) або загальними (модель змінилася); представлення може запитувати модель у відповідь на повідомлення про зміну. У поданні представлений потрібний набір елементів моделі на екрані, оновлення екрана, як при обробці сповіщень про зміни.
Контролер повинен натиснути на зміни моделі в результаті вказівки користувача (наприклад, клавіатура в клавішах, команди миші та меню).
Модель підтримує модель та перелік підписок, а також має повідомляти про перегляди відповідних змін за допомогою своїх підписок.
Також повинен бути механізм для створення нових поглядів і контролерів (оскільки в MVC ви повинні мати два або більше представлень однієї моделі (вони можуть бути однаковим видом (точкою) або іншим видом (точкою)). Логічно, ми можемо вважати, що контролеру потрібно виконувати або мати доступ до фабрики перегляду та контролера (пари), яка може бути частиною контролера або іншого компонента.
Modelsне повідомляти Views. Controllersзапитайте Modelзміни, а потім візьміть Viewsдля подання цих змін.
MVC більше нагадує модель модульності. Її мета полягає в тому, що коли ви хочете змінити макет інтерфейсу користувача (перегляд), вам не доведеться змінювати логіку програми (контролер) або внутрішні обробки даних (модель).
Для того, щоб досягти цього, закономірність полягає у виділенні логіки реалізації кожного компонента MVC. І все-таки цілком нормально, що там компоненти знають інтерфейси один одного .
Я часто бачив, що контролер створює або викликає модель та перегляд (таким чином, він знає їх інтерфейс), а модель або перегляд можуть сповіщати контролера у відповідь (більше, як зворотний виклик або модель спостерігача). Важлива частина полягає в тому, що контролер не знає структури компонування.