Пара философских вопросов о MVC - Страница 3

Psycho Tiger · 08.01.2011, 22:25

Ещё пара слов:
есть какой-то запрос от пользователя. Например, ввод фильтра. С помощью контроллера мы этот самый фильтр отправляем всячески наверх просто событием. И сегодня вводим с клавиатуры, завтра клацаем мышкой, а послезавтра вводим голосом.
Обрабатываем данные тоже вне зависимости от того, как они там будут хранится. Меняем логику работы без вмешательства во внутреннее хранение. Как они будут упорядочены, как они будут отсортированы - это логика другого уровня, другой абстракции. Если смешивать что-либо, то придется в голове неизбежно оперировать как хранением, так управлением, так и отображением. Конкретно мне, когда число классов в проекте больше 50 это делать сложно. А их очень часто больше 200.

Добавлено через 5 минут
@silin: ты работал в динамично развивающимся проекте, в котором каждую неделю нужно что-то добавлять, менять, дорабатывать, переделывать, интегрировать или с маразматичными людьми, которые хотят использовать баннер как мозги для панелей управления космических шатлов и наоборот?

Вот я как-то, когда уже вполне освоил MVC и применял его взялся за проект, такой, маленький. Всего за 300$, пару вечеров посидеть. Подумал - а к черту этот MVC, всё так просто! Потом что-то поменялось, потом ещё, потом ещё... после 2-х недельной запарки я поклялся, что больше никогда не брезгну MVC по причине "это слишком простое задание, чтобы его применить". Будь проект на нём - эти 2 недели (задержки не по моей вине были) я тратил бы на проект 15 минут вечером - подкрутить, а не час-полтора.

JackFromChaos · 08.01.2011, 23:04

Цитата:

Сообщение от mikhailk

Все правильно, в классическом понимании MVC контроллер должен быть "тонким". Но все-таки я бы предложил относиться к паттерну проектирования без лишнего фанатизма. На текущий момент нет единой реализации MVC, с которой согласны все абсолютно.

А если подходить без лишнего фанатизма, то в моем понимании, правило о том, что представление не должно давать команды моделе не верно. Мне нравится концепция умных визуальных компонентов, ака кубиков из которых удобно, быстро и легко строить представление которое напрямую общается с моделью, а не реализовывать один и тот же функционал написаниям когда в 2 разных модулях. Т.е. архитектура скорее MVVM.
Просто о MVC так много говорят, что решил разобраться...
К сожалению, или к счастью, не пришел к выводу, что это чем то лучше, чем то, как я программировал ранее.
А по поводу логики, мое кунг фу говорит мне, что вся бизнес-логика(как пример, РПГ система) должна реализовываться на уровне исключительно модели. Не потому что я придерживаюсь какой то там буквы, а просто мне кажется это правильным.
Т.е. я отдельно могу проектировать саму систему. Отдельно – ее представление.
Причем в идеале, для представление пишется ряд кубиков-компонентов, из которых строится система путем настройки связи с моделью и настройками, и остается только рутина и минимум работы. А если игра достаточно сложная, то все остальное время можно посвятить реализации логики игры, т.е. модели которая обычно куда менее универсальна.

Добавлено через 4 минуты

Цитата:

Сообщение от Psycho Tiger

@silin: ты работал в динамично развивающимся проекте, в котором каждую неделю нужно что-то добавлять, менять, дорабатывать, переделывать, интегрировать или с маразматичными людьми, которые хотят использовать баннер как мозги для панелей управления космических шатлов и наоборот?

Я писал...

mikhailk · 08.01.2011, 23:35

Цитата:

А по поводу логики, мое кунг фу говорит мне, что вся бизнес-логика(как пример, РПГ система) должна реализовываться на уровне исключительно модели. Не потому что я придерживаюсь какой то там буквы, а просто мне кажется это правильным.

Тут как бы надо все-таки разобраться, о чем идет речь. Если говорится о типовой многопользовательской игре, вся бизнес-логика все равно живет на сервере. Клиент обеспечивает визуализацию того, что получает от сервера, ожидает событий мышки/клавиатуры, отправляет соответствующие им запросы на сервер и на этом фактически весь его функционал заканчивается.

Здесь на форуме все-таки идет речь о реализации клиента. И бизнес-логика в этом контексте - это не бизнес-логика приложения, а бизнес-логика клиента.

andrew911 · 09.01.2011, 00:17

Цитата:

Сообщение от JackFromChaos

А по поводу логики, мое кунг фу говорит мне, что вся бизнес-логика(как пример, РПГ система) должна реализовываться на уровне исключительно модели. Не потому что я придерживаюсь какой то там буквы, а просто мне кажется это правильным.

Представьте, что вы получаете данные от сервера, обрабатываете моделью.
Теперь протокол поменялся / изменился источник данных (вы решили подключить АПИ одноклассников, вместо АПИ вконтакта) - будет удобнее переписывать модель или просто переключить ответственный контроллер (а в моделе сохранять данные).

JackFromChaos · 09.01.2011, 00:18

Цитата:

Сообщение от mikhailk

Тут как бы надо все-таки разобраться, о чем идет речь. Если говорится о типовой многопользовательской игре, вся бизнес-логика все равно живет на сервере. Клиент обеспечивает визуализацию того, что получает от сервера, ожидает событий мышки/клавиатуры, отправляет соответствующие им запросы на сервер и на этом фактически весь его функционал заканчивается.

Здесь на форуме все-таки идет речь о реализации клиента. И бизнес-логика в этом контексте - это не бизнес-логика приложения, а бизнес-логика клиента.

Почему обязательно ммо? К примеру осенью я делал сингловую аркаду с рыбками, с перками, абилками, обкастами... А для игр вроде Hidden Object так вообще, имхо, разделение представления и модели - не нужно, так как жанр сам по себе очень визуальный... Там логика из графики состоит

А на счет все логики на стороне сервера, скажем для соц игр это может быть верно лишь отчасти... своя специфика, и частично на стороне клиента нужна логика, зачастую дублирующая сервак.
Например заказчик говорит, все в игре должно происходить мгновенно, без всяких ожиданий от сервера(и где то он наверное прав, потому что некоторые игры иной раз бесят своей тормозутностью по каждому клику). Ну и приходится изголятся...

Добавлено через 5 минут

Цитата:

Сообщение от andrew911

Представьте, что вы получаете данные от сервера, обрабатываете моделью.
Теперь протокол поменялся / изменился источник данных (вы решили подключить АПИ одноклассников, вместо АПИ вконтакта) - будет удобнее переписывать модель или просто переключить ответственный контроллер (а в моделе сохранять данные).

Где бы у меня не реализовывалась апи соц сети, в моделе или контролере, она в любом случае будет основана на полиморфизме, с выделением базового класса или интерфейса и реализацией для разных сетей...
ООП, да и те же паттерны ведь никто не отменял? Такое ощущение, что все парадигмы и концепции ООП вдруг оказались ввнутри стратегии MVC, и за пределами ее вне существуют%)

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

andrew911 · 09.01.2011, 00:30

Цитата:

Сообщение от JackFromChaos

Где бы у меня не реализовывалась апи соц сети, в моделе или контролере, она в любом случае будет основана на полиморфизме, с выделением базового класса или интерфейса и реализацией для разных сетей...
ООП, да и те же паттерны ведь никто не отменял? Такое ощущение, что все парадигмы и концепции ООП вдруг оказались ввнутри стратегии MVC, и за пределами ее вне существуют%)

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

МВЦ это и есть паттерн. Никто не спорит, что есть и другие паттерны.
Возможно, прийдется менять и представление - оно для того и существует, чтобы можно было менять его, используя одну модель.
А вот насчет модели вероятность гораздо меньше, по сути везде нужен один набор данных.

Вы пытаетесь разобраться или просто откинуть все теории кроме своей?

Psycho Tiger · 09.01.2011, 00:33

Полиморфизм, базовые классы и всё-всё это очень здорово. Только в реальной жизни гораздо лучше иметь под рукой и плюшки полиморфизма, и возможность переключить контроллер. А в командной разработке переключить контроллер куда проще, чем наследоваться от чьего-то другого класса. В случае наследования мы работаем с внутренней реализацией класса (которую ещё, возможно, придется допиливать чтобы можно было унаследоваться более-менее с головой), а в случае с переключением контроллера - с его внешним API, который, как правило, не нуждается в допилке, более безопасный в использовании, дружественный и документированный.

JackFromChaos · 09.01.2011, 01:02

Я уже не особо пытаюсь разбираться... Потому как выше мы пришли к выводу, что здесь используется не классический MVC, а тот самый, который описа в вике как ТТУК.
Для перехода на новую соц апи Базу Данных менять не придется. Но классическая MVC модель это нечто большее чем БД. Для того что бы поменять соц апи, нужно менять не только клиент, но и сервер. Но как заметил mikhailk, здесь обсуждается только клиентская часть... А я не умею мыслить о клиенте отдельно, для клиент-серверного приложения. Для меня это целостная система.

Если АПИ должно переключатся с помощью контроллера, я готов с этим согласится. Но тогда нужно определится, с комплексной архитектурой, т.е. на клиенте MVC, что тогда на сервере? С чем общается клиент(имеется с каким модулем, контроллер, модель...), ну и т.д. Потому что из поста выше я как то не смог представить всю картинку в целом...

P.S. Извиняюсь если как то не так себя веду... Я не планировал разжигать никаких холиваров и споров...
P.P.S. Волне впозможно что я вообще не прав, и мне просто сложно перестроиться...
"Речь, конечно же, пойдёт о человеке растущим на флеше с 0, а не матёрым Java`ером, который решил переквалифицироваться."
Я не Флэшер растущий с нуля. Я увлекаюсь программированием уже около 20 лет, работаю по специальности около 14, и может даже уже немного закостенел... А вот первая моя Flash-ка написанная от начала до конца, как продукт, на работе была сделана прошлым летом(до этого Flash-ем я занимался чисто ради развлечения, в свободное от работы время).

mikhailk · 09.01.2011, 01:16

Цитата:

Но тогда нужно определится, с комплексной архитектурой, т.е. на клиенте MVC, что тогда на сервере?

Для клиента сервер скрыт за моделью.

Но, по большому счету говорить о какой-то единой архитектуре для клиента и сервера я бы не стал. В общем виде. Есть проекты, которые имеют сервера на Эрланге. Там вообще никакого ООП в принципе нет и быть не может, это функциональное программирование в чистом виде.

Хомяк · [+1 24.11.10]

Цитата:

Сообщение от andrew911

Представьте, что вы получаете данные от сервера, обрабатываете моделью.
Теперь протокол поменялся / изменился источник данных (вы решили подключить АПИ одноклассников, вместо АПИ вконтакта) - будет удобнее переписывать модель или просто переключить ответственный контроллер (а в моделе сохранять данные).

слышали что нибудь про паттерн Connector?

Добавлено через 4 минуты

Цитата:

Сообщение от andrew911

МВЦ это и есть паттерн....

MVC - не паттерн, а архитектурное решение. Это MVC может реализоваться рядом паттернов, но не наоборот.