MVC: грамотная архитектура проекта

[Wolsh]

Да просто не раз попадались предложения не лукавить и делать напрямую. Признать, что на самом деле, особенно если говорить о конкретном проекте, Вью пишется для Модели, а не ЛюбойМодели, а Контроллер пишется для Вью — по сути, для каждого Вью. И что разнесение их с помощью Событий звучит красиво, пока рассматривается пример с одним кликом по кнопке. Но в случае игры появляется 100500 уникальных типов событий, к тому же несущих в себе данные, и ежу понятно что Вью, посылая событие, рассчитывает на реакцию, а Контроллер обязан знать именно этот конкретный тип события, что хочешь-не хочешь а создает сильную связанность Вью и "его"(!) Контроллера и плодит бесконечные классы Событий, иногда описывающих одно-единственное действие во Вью. И как альтернатива предлагается отказаться от Событий между Вью и Контроллером, заменив ОБЩИЙ СПИСОК событий Интерфейсом Контроллера, дергая его методы напрямую. То есть Вью "ожидает" весьма конкретный контроллер, понимающий все задачи Вью. И я склонен соглашаться, что иногда в конкретных проектах в этом нет ничего дурного. Очень радует фраза GoF в их книге о паттернах, когда они рассказывают концепцию MVC в начале книги и приводят Схему MVC с примечанием: "на Схеме не показаны Контроллеры для простоты понимания". Вот как-то так. Контроллер — всего лишь придаток Вью, собирающий в одном месте, удобном для редактирования, логику взаимодействия Вью с Моделью, позволяя в собственно Вью сконцентрироваться только на визуалке. Этакий набор методов Вью для дерганья Модели, чем по сути контроллер и является.

[Akopalipsis]

В день я раз по двадцать переписываю всё с начала и не как не могу найти хотя бы простое решение реализации. Но мне очень бы помог совет опытных - предположим, есть главное окно приложения, оно контролируется главными mvc. Есть два окошка, одно показывает минуты, а другое секунды. Собраны эти окошки тоже по mvc, то есть у каждого окошка своя модель, вью и контроллер. Добавляются они естественно во вью, но как, у этих окошек точкой входа в главное приложение будет их класс Main?

[Psycho Tiger]

Ну, контроллер должен уметь добавлять вью в общий дисплайлист.
По идее, раз тут зеркальное отображение модель - вью, то выглядит это так:
1) Создается главная тройка.
2) В модель вкладывается другая модель (по-сути это addChild). После вложение диспатчится событие ADDED.
3) Главная вью ловит событие ADDED и видит: ага, да это же секундомер. Сама создаёт вью секундомера и даёт ему модель.
4) Контроллер, попивая коктейльчики, отдыхает.

P.S. на днях постараюсь опубликовать 3 часть статьи, там как раз схожий пример.

[Akopalipsis]

Psycho Tiger пусть я буду выглядеть невежей, но я сразу перейду к - долгожданному продолжению!) я скажу, что я бы хотел подчерпнуть из Вашей статьи и я уверен, что не я один этого хочу:
1) Во всех примерах ( в Ваших, в книгах ) всегда показывают на минимальном примере, всех по одному.
И по этому очень хотелось бы видеть, как устроена архитектура, когда все фигурантов минимум три.
я уже две недели не могу сделать вот что - я ставлю себе задачей сделать
MainMenuView,GameView,GameOverView.
MainMenuModel,GameModel,GameOverModel.
MainMenuController,GameController,GameOverController.
Соответственно ( я могу ошибаться ) есть базовые фигуранты и главные фигуранты - MainModel, MainView и MainController, которые наследуются от своих базовых классов и создают в себе все классы, которые я перечислил выше. То есть без графики без всего, просто минимум, но у меня не получается полноценно передавать ссылки. я не прошу всё делать так как Вы все делаете в жизни, мега секретные парсеры массивов или что то ещё, не надо. Но если можете сделайте максимально возможную архитектуру приближенную к реальности.
2) Отдельным пунктом хочется попросить сделать максимально приближенным к жизни, инициализацию
всей цепочки, в жизни же MVC это архитектура состоящая из других паттернов, вот её и хотелось бы увидеть.
И даже ненужно поэзии и каких то видов, квадратики вполне подойдут.
И Спасибо Вам!

[Dukobpa3]

на самом деле, особенно если говорить о конкретном проекте, Вью пишется для Модели, а не ЛюбойМодели, а Контроллер пишется для Вью — по сути, для каждого Вью.

Ну не соглашусь.....
Вернее вроде бы и соглашусь, но как-то коробит от такого.
И чтоб в моих проектах такой фигни не встречалось я просто добавил класс медиатора.

Итого на весь проект получается:
- штуки 4-10 контроллеров.
- много моделей (два дерева моделей)
- много вьюх
- медиаторов примерно в три пять-раз меньше вьюх.

Вью диспатчит не в контроллер а в медиатор, и медиатор умеет слушать не СВОЮ вью, а СВОЙ ВИД вью.
Например медиатор окон, медиатор попапов.
И потом уже медиатор, заворачивает событие вью в какую-то абстракцию и шлет контроллеру(ам), может и на сервер послать, если это не требует логик. (Ну как в магазине кнопка купить, тут просто запрос отослать надо. Никаких даже проверок, так как проверки раньше сделаны в модели, и раз уж пользователь смог нажать кнопку - значит ему это позволили сделать).

Короче дополнительный слой абстракции упростил понимание системы и очистил паку *****кода и хардкода в контроллерах.

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

[in4core]

Dukobpa3 - с такой архитектурой сразу ставьте крест на своей карьере программиста. Такой код не только читать, его самому сложно понять. Это очередные извращения. Почему не делать все просто? Ведь простота залог успеха. Если приложение не сильно большое достаточно 1-2х контроллов, много моделей(если надо) и вьюх. Вот к примеру, я как то делал слот автоматы, думаю не стоит объяснять что это.
1 основной контроллер для захвата сервера, запрос-ответ, все просто. Основная вьюха при спине делает запрос, контрол лезет на сервер отдает значение модели, основная вьюха и сопутсвующие ей подхватывают от моделей то, что нужно. Это читабельно и понято - это чистый приятный MVC. Далее создаем еще один контрол, для связи видов GUI . Вид с линиями и вид с кнопочками, они пересекаются между собой, поэтому контрол там очень кстати. Все. удобно и хорошо. При этом я не могу сказать, что это МАЛЕНЬКОЕ приложение, оно довольно приличное.
В вашем же случае подход может быть оправдан наверное к примеру, в приложении аналога фотошопа с сервером. Хотя тоже извращение.
Я сетую и буду сетовать и призывать всех здравомыслящих людей пользоваться pure - ибо это читабельно , понятно, и просто в доработке.
Опять же никто не скажет какой путь верный для конкретного проекта, путей много. Но сколько бы разных проектов я не делал, и переписывал их по 100 раз, как начинающий Akopalipsis, дабы найти нирвану, и в итоге какой бы проект я сейчас не делал - пуре спасает и еще ни разу, я не поймал себя на мысли, что я сделал криво, и можно было бы лучше, после того, как я перешел на чистый.

[Dukobpa3]

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

ставьте крест на своей карьере программиста

лол) ок)
Только я сейчас синьор дев + мид архитект в топовой(три месяца назад перегнали зингу по баблу) конторе пишущей для ФБ.
И боюсь те проекты которые я пишу - ты даже собрать не сможешь

//*****************
Но про крест на карьере программиста уже и сам задумываюсь)) Открою барчик вон как блад) Буду к пиву ближе и к людям А то всё код да код) Скучно стало жить.

Добавлено через 4 минуты
И да. про пурмвц я могу много рассказать
Это просто инструмент, и писать на нем неадекват очень легко
Хотя во многих случаях это лучше чем свои велосипеды банально потому что вся компания "почти одинаково" пишет(на практике это нифига не так получается).

Добавлено через 5 минут
Если вы не видели последовательного екстенда команды с оверрайдом екзекьюта - вы не видели пурмвц в действии)))))))
(Я когда первый раз увидел - испугался теперь привык, просто ржу)

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

я не поймал себя на мысли, что я сделал криво

Вот зря

[in4core]

Dukobpa3 - пуре МВС не имеется ввиду фреймворк. А имеется ввиду своя реализация , основанная на четких постулатах MVC.
*Только я сейчас синьор дев + мид архитект* Я готов с тобой поспорить , ты работаешь с 8(9-10) до 6(7-8) сидя в офисе целый день. А я работаю когда захочу и сколько захочу, при этом ЗП у меня выше или равна вашей привет
Я даже больше скажу, любой лось может устроится в топовую компанию типа mail.ru легко и непринужденно. Отпахать там на дядю пару лет и выбиться в тим лиды например. Этим уже никого не удивишь. Очень часто, тем более сейчас стало можно, брать средней руки программиста, обучить и т.п. Топовая компания это Samsung например, или из веб Google. Вы работаете в одной из них и вас ценят как лучшего работника? Если так, я преклоняюсь перед вами

P.s. про бар хорошая идея, только боюсь ваших ЗП не хватит , чтобы его открыть, содержать, и развивать. Хотя да, щас же кредит есть, так о чем это мы ... ах да о программировании

[Dukobpa3]

Я готов с тобой поспорить

Вот поспорить ты всегда готов, в этом никто не сомневается. Только, не факт, что аргументы адекватные в этих спорах будут

[in4core]

Ну как же, аргументы на лицо. Приведены выше, что такое топовая компания, и чем отличается работа в офисе от свободного заработка. Ну дело не в этом. Я же говорю со своей колокольни, и я понимаю о чем я говорю, я программирую наверное побольше чем ты, хотя может и меньше, не суть, опыт у меня довольно богатый в этом. То, что я многого не знаю - я не отрицаю, я например никогда не работал с 3д и не буду комментировать это, дабы не знаю о чем речь вести. А вот про архитектуру я могу спорить, дабы этот опыт есть у всех и у всех он свой, со своей стороны я ответил - чистый МВС , как написано в справке - по моему мнению самый удобоваримый паттерн во всех направлениях, что в больших, что в малых проектах. Да бы на данный момент я не чуствую нужды переписвать проекты по 100 раз, как мне хотелось это ранее ища лучшее решение.
И да, простите, никаких оскраблений, просто не удержусь. Как Задорнов про Мерчендайзеров* говорил, синьор дев - синьор Помидор! Вот кто! Просто эти современные названия настолько смешно звучат, что ужас, при этом они не говорят ничего толкового. Я бы просто назвал разработчик ПО или разработчик ИГР. Это понятно и вопросов не возникает.