MVC на практике при разработке windows-приложений
http://blogs.mail.ru/mail/mactep.het/?Password=&Domain=&Login=#5EFF6550BFAB77C3
Поделитесь своим мнением о возможных альтернативах этому подходу:)
Если честно, я бы очень удивился, если бы ветеран программирования подчерпнул бы для себя что-то новое из этой статьи. Она ориентирована прежде всего на начинающих кодеров.
Если честно, я бы очень удивился, если бы ветеран программирования подчерпнул бы для себя что-то новое из этой статьи. Она ориентирована прежде всего на начинающих кодеров.
Истины на то и прописные, что бы их не прописывать :D
А если статья рассчитана на совсем начинающих, то следовало бы поменьше применять заумных слов типа "интерфейс", "фабрика объектов", либо в начале дать им четкое и понятное определение (можно и с примерами). Ну и код реальный лучше выложить (чисто определение классов и методов, без указания реализаций)
А если статья рассчитана на совсем начинающих, то следовало бы поменьше применять заумных слов типа "интерфейс", "фабрика объектов", либо в начале дать им четкое и понятное определение (можно и с примерами). Ну и код реальный лучше выложить (чисто определение классов и методов, без указания реализаций)
Ну начинающих, имеется ввиду уже знакомыми с подобными понятиями или по крайней мере желающими ознакомится.
Википедия объяснить про эти понятия может гораздо лучше меня, так что пожалуй вставлю в статью ссылки на данные понятия.
А по-поводу примера актуальное замечание надо сказать...
PS:
Кстати не смотря на очевидность схемы построения приложения, еще ни разу не доводилось встречать её реализацию на практике.
Чаще всего логику зашивают прямо в интерфейс. В результате приложение разбухает,- из-за усложнения бизнес правил. И в дальнейшем из-за невозможности проведения нормального тестирования начинает валиться у клиентов. Научен горьким опытом так сказать:)
Должны работать следующие сочетания модулей:
1. Модель + Контроллер + Консольный Вид.
2. Модель + Контроллер + Вид с GUI.
В обоих сочетаниях должны быть одни и те же Модель и Контроллер. В виде не должно быть никаких вычислений, работы с файлами, базами данными и т.д. Только работа с пользователем. И нигде не должно быть дублирования кода. Всё. Можно изобретать велосипед, который позволит что-то понять.
Кстати, а нужен ли там синглетон?
Однозначно нужен. Фабрика интерфейса - это сервис предоставляемый приложению. Логично предположить, что сервис должен быть один в контексте всего приложения.
Более того сочетание "Абстрактная фабрика" + "Синглтон" - считается обыденным.
Теория этот как раз то о чем нам только что поведал, а в статье предоставлена конкретный способ реализации данной схемы:)
Есть ведь наверно и куча других способов построения приложений с интерфейсом, удовлетворяющих требованиям MVC...это один из...
А практический пример: есть клиент к базе данных, по которому собственно и написана статья.
Я его кастрирую и обязательно выложу для наглядности...хотя и так все дотошно рассказано, что куда и сколько раз...
Кстати для n-звенных систем, как мне кажется данная схема будет еще более ценной, чем для 2ух.
Кстати не смотря на очевидность схемы построения приложения, еще ни разу не доводилось встречать её реализацию на практике.
Чаще всего логику зашивают прямо в интерфейс.
В чистом виде редко кто применяет в настольных приложениях. Наибольшую отдачу подход дает в системах, работающих с обширными БД с толпами сущностей и зависимостей между ними. Игры тоже пытаются ему следовать, но там своих проблем хватает. Еще это особенно касается веб-приложений, они основные кандидаты на применение подхода MVC.
Почему это логично? Для маленького приложения может и логично. Для очень маленького и глобальные переменные могут быть логичными.
А если потребуется наследника сделать этому синглетону? Будет не очень хорошо.
Если мы добираемся к Интерфейсу (Модели, Контроллеру и т.д.) по цепочке объектов, то можно проследить, кто "прицепился" к нему. А с синглетоном можно получить неизвестно откуда присылаемые в интерфейс данные.
Например, кто-то из команды разработчиков решил прицепить к Интерфейсу через Синглетон ещё одну тестовую Модель, которая при стечении определенных редких обстоятельств будет посылать Интерфейсу сообщения. Потом забыл её убрать, так как эта Модель себя не проявляла. А при сдаче проекта она и всплывет. Или ещё позже.
Ну и юнит-тесты тут могут забуксовать... Но это как пример недостатков.
Оно может и теория, но это задача для практики, для изобретения, для понимания. А то, что приведено по ссылке - это готовое решение, которое в мозг хуже ляжет.
