Comments 32
Опрос размещен в рамках моральной подготовки к написанию следующей фундаментальной статьи по MVC. Если у вас есть вариант ответа, не укладывающийся в эти четыре — с интересом выслушаю его в комментариях.
P.S. Напоминаю, что рассматривается именно desktop приложение. Как notepad :).
P.S. Напоминаю, что рассматривается именно desktop приложение. Как notepad :).
Как по мне, автообновление — это дополнительная фича (как плагин или хук).
Любые сервисные подсистемы лучше выделять в отдельные компоненты. Но, если у этой подсистемы будет интерфейс, его лучше разместить во вью, если будет хронология или журнал обновлений — в model, если я могу инициировать обновление сам — понадобится контроллер. Собственно говоря, MVC — суть фронтенд к сервису, которым зачастую выступает СУБД, но это может быть и сервис автообновления. Так что его код запросто может быть размазан по всем перечисленным зонам ответственности.
Все просто, кто изменился, тот и уведомляет виды об изменениях. Только уведомляет!
Хмм… Пи автообновлении вроде никто не изменился — мы нашли новую версию и хотим об этом сказать пользователю. Вопрос — где поместить код, который будет эту самую новую версию искать?
Нужно последовательно идти. Сначала Passive View, когда ничего не обновляется.
Что нужно сделать, чтобы обновить? Перезапустить. А значит мы имеет уже процесс обновления!
Теперь что нужно, чтобы процесс обновления был запущен? Когда он должен быть запущен? Ответы на эти вопросы и будут конечной реализацией. Самое простое, оповещать все виды при обновлении данных, чтобы они обновились. Что управляет данными и операциями над данными? Правильно модель!
Другое решение, виды должны наблюдать за моделью. Т.е. подписываться на изменения и в случае если оно происходит, обновляться. Это даже чуть элегантнее, хотя вводит процесс подписки.
А если посмотреть на проблему более глобальнее, то есть подходы более простые и элегантные. Но для этого стоит погрузится в обучение функциональным программированием. Чтобы не быть голословным, вот ссылка.
Что нужно сделать, чтобы обновить? Перезапустить. А значит мы имеет уже процесс обновления!
Теперь что нужно, чтобы процесс обновления был запущен? Когда он должен быть запущен? Ответы на эти вопросы и будут конечной реализацией. Самое простое, оповещать все виды при обновлении данных, чтобы они обновились. Что управляет данными и операциями над данными? Правильно модель!
Другое решение, виды должны наблюдать за моделью. Т.е. подписываться на изменения и в случае если оно происходит, обновляться. Это даже чуть элегантнее, хотя вводит процесс подписки.
А если посмотреть на проблему более глобальнее, то есть подходы более простые и элегантные. Но для этого стоит погрузится в обучение функциональным программированием. Чтобы не быть голословным, вот ссылка.
Простите, но так и хотелось сказать: пишите код, блять!
PS: А вообще код автообновления скорее всего д.б. где-то в отдельном процессе, где никакого MVC вероятно и не нужно :)
PS: А вообще код автообновления скорее всего д.б. где-то в отдельном процессе, где никакого MVC вероятно и не нужно :)
Методология хорошая, но есть один минус — через годик-другой написания кода, блять, может случиться так, что внесение новых изменений будет дороже, чем переписать с нуля. И мат, что характерно, ничем не поможет — потому что архитектурные проблем, дэс О_О.
ну это стандартный аргумент против «пишите код, блять».
И как вообще Agile может работать — надо же вначале архитектуру расписать, и расстреливать за шаг вправо или влево — а то архитектурные проблемы будут через годик-другой… Ну в общем, мысль ясна. Закрываем тэг «сарказм».
Смысл вышенаписанного в том что просто писать код может привести к архтектурным проблемам, но может и не привести. Для этого в Agile подходах есть разные техники как избежать архитектурных проблем, не расписывая архитектуру на десять лет вперед с точностью до имен классов.
И как вообще Agile может работать — надо же вначале архитектуру расписать, и расстреливать за шаг вправо или влево — а то архитектурные проблемы будут через годик-другой… Ну в общем, мысль ясна. Закрываем тэг «сарказм».
Смысл вышенаписанного в том что просто писать код может привести к архтектурным проблемам, но может и не привести. Для этого в Agile подходах есть разные техники как избежать архитектурных проблем, не расписывая архитектуру на десять лет вперед с точностью до имен классов.
Этот манифест не имеет ни малейшего отношения к архитектуре, а имеет отношение к идиотским методологиям ради методологий и бурно имитирующим деятельность ПМ.
Не путайте понятия, блять.
Не путайте понятия, блять.
Автообновления чего?
Я сначала подумал, что речь идёт об автоматическом обновлении данных.
Я сначала подумал, что речь идёт об автоматическом обновлении данных.
Код автообновления по идее имеет очень слабое отношение к основному коду. А поэтому должен быть полностью отделен (разве что кроме интерфейсной части). И ничего не мешает организовать код автообновления как параллельный к основному коду mvc.
BTW, интереса ради — а код экспорта результатов в PDF имеет отношение к основному коду или нет? :). Как легко провести границу между «основным кодом» и «вспомогательным кодом»?
Имхо к основному коду имеет отношение некий метод, который возвращает результат в некоей форме. А экспорт в pdf, html, txt, xml или еще какой-то формат — все-таки внешний модуль. Потому что вперло заказчика, что он не проприетарный формат хочет, а какой-то общий — и лезь в основной код править.
Результат в pfd, html, txt, xml — это не «результат в некоей форме»? Противоречите сами себе.
Любая сериализация данных в любой формат или любое формирование отображения — это вполне себе пользовательский юзкейс, нужный для выполнения неких пользовательских задач.
Любая сериализация данных в любой формат или любое формирование отображения — это вполне себе пользовательский юзкейс, нужный для выполнения неких пользовательских задач.
Я имел в виду некую не привязанную в финальному виду того, во что мы экспортим, промежуточную, форму — массив объектов, например, как самое простое. Чтобы не пришлось потом переписывать кусок исходного кода основной программы, чтобы он делал xml, а изменять это в том самом «внешнем модуле».
Эээ… Ну вы как бы сейчас и описали основной смысл mvc ;)
Ну вообще я так и собирался :) Я пытался ответить на Ваш вопрос про экспорт pdf — возможно, я не понял, что он был риторическим или содержал тэг сарказм ;)
Попробую подробнее объяснить мысль — экспорт в pdf, как и любая другая визуализация данных, выполняет некий шаблонизатор, который с одной стороны является часто сторонним модулем, но с другой стороны, ИМХО, это все-таки часть слоя View, независимо от того в какие форматах и в каком их количестве может отдавать данные наша система.
Я понимаю Вашу мысль, но то, что сказал я — это, фактически, то же самое, только разделенное на две части — и внутренняя часть, выдающая данные — может быть частью view, а конкретная реализация записи в каком-то формате или форматах — внешней частью. Тогда не будет этой неопределенности — что и туда, и туда относится экспорт — это две разных части. Тем более, что внутренняя часть может использоваться разными внешними частями.
Элементарно:
1. Основной код непосредственно отвечает за выполнение бизнес-задач пользователя.
2. Вспомогательный код обслуживает основной код (обновляет, например).
Код экспорта в pdf должен лежать во View, там же где лежат и другие генераторы и визуализаторы отображения (и да, я тут не вижу сильно большой разницы между десктоп и веб).
1. Основной код непосредственно отвечает за выполнение бизнес-задач пользователя.
2. Вспомогательный код обслуживает основной код (обновляет, например).
Код экспорта в pdf должен лежать во View, там же где лежат и другие генераторы и визуализаторы отображения (и да, я тут не вижу сильно большой разницы между десктоп и веб).
Сорри, это ответ на вот этот комментарий
Что-то я уже боюсь фундаментальную статью по MVC писать. Меня ж порвут как оргский герой Тезик саблезадого тигра Грелку. И никакой запас кармы не поможет О_О.
Мда…
У автообновления есть ввод выбора пользователя «да, жги!» и «не, потом»? — Это контроллер.
У автообновления соот-но наверняка есть окно где этот выбор реализован в виде пары кнопок, прогрессбара и т.п.
— это представление.
А версионирование, хранение файлов и т.п. бизнес-логика автообновления — это модель.
Почему целое должно умещаться в треть и зачем его туда пихать — вот вот это уже интересный вопрос.
У автообновления есть ввод выбора пользователя «да, жги!» и «не, потом»? — Это контроллер.
У автообновления соот-но наверняка есть окно где этот выбор реализован в виде пары кнопок, прогрессбара и т.п.
— это представление.
А версионирование, хранение файлов и т.п. бизнес-логика автообновления — это модель.
Почему целое должно умещаться в треть и зачем его туда пихать — вот вот это уже интересный вопрос.
В контроллер, т.к. событие «попытайся обновиться» не отличается от события «нажали кнопку»
ну а далее — если надо тянем модель, показываем формы итд
ну а далее — если надо тянем модель, показываем формы итд
Т.к. MVC — это не шаблон проектирования, а стратегия разработки, или мета-шаблон, то, соответственно, ответ на вопрос зависит от конкретной реализации MVC, от того, что подразумевается под приложением, от понимания MVC.
Например, если используются инициирующий класс для создания Модели, Отображения и Контроллера, то автообновление можно засунуть в него.
Если под приложением понимать непосредственно само приложения, не рассматривая сервисы, которые предоставляет среда, то тогда автообновление можно вообще вынести за пределы приложения и соответственно MVC, отдав эту функцию окружающей среде.
Другой вариант — это засунуть автообновление в загрузчик. В зависимости от понимания MVC, загрузчик можно рассматривать и как внешний модуль, и как компонент Отображения, и как инициирующий класс.
Т.е. вариантов очень много, часть уже указали выше.
Например, если используются инициирующий класс для создания Модели, Отображения и Контроллера, то автообновление можно засунуть в него.
Если под приложением понимать непосредственно само приложения, не рассматривая сервисы, которые предоставляет среда, то тогда автообновление можно вообще вынести за пределы приложения и соответственно MVC, отдав эту функцию окружающей среде.
Другой вариант — это засунуть автообновление в загрузчик. В зависимости от понимания MVC, загрузчик можно рассматривать и как внешний модуль, и как компонент Отображения, и как инициирующий класс.
Т.е. вариантов очень много, часть уже указали выше.
Велосипед уже изобретен, автообновление предоставляется ОС, например менеджером пакетов типа aptitude :)
А если серьезно, то сам код автообновления (стукнуться на сервер, проверить версию, скачать если есть новая) — это модель. Обращение к ней происходит из контроллера по какому-=то событию (например запуск программы), если нужно отобразить инфу для пользователя — то это вью. В этом смысле автообновление ничем не отличается от других задач.
А если серьезно, то сам код автообновления (стукнуться на сервер, проверить версию, скачать если есть новая) — это модель. Обращение к ней происходит из контроллера по какому-=то событию (например запуск программы), если нужно отобразить инфу для пользователя — то это вью. В этом смысле автообновление ничем не отличается от других задач.
Sign up to leave a comment.
Где в MVC desktop приложении вы разместите код автообновления?