Внесите, пожалуйста, ясность в MCV.
 

По MCV: Есть контроллер (С1), есть у него модель (M1). В С1 я создаю другой объект который тоже состоит из контроллера (С2) и модели (М2), и таких объектов может быть много в С1. Мне нужно в М1 делать расчеты которые связанны со всеми объектами принадлежащие С1, а значит нужны нужны ссылки на них и при чем не конкретно на них, а на модели этих объектов (М2-Мn).

1) Правильно ли хранить ссылки на модели дочерних объектов С1 в М1?
2) Если нет то как мне обращаться к моделям дочерних объектов из M1, ведь мне нужно использовать их для расчетов.

1) правильно, ветвление модели (у тигера почитай)

пояни вот эту фразу: "В С1 я создаю другой объект который тоже состоит из контроллера (С2) и модели (М2)"

1 - Модель предстваляет собой паттерн компоновщик.
2 - У базового контроллера есть ссылка на на модель.
3 - У всех контроллеров есть сслыка на базовый, через него можно получить и ссылку на базу данных (модель).

А зачем? Всегда можно сделать контрллеру публичный геттер на его модель, и тогда у Вас всегда будет ссылка на модель, если есть ссылка на контроллер.

Во...... вот так делать правильно. Тобишь чтобы мне что-то посчитать в базовой моделе, мне нужно чтобы базовый контроллер обратился к каждому дочернему контроллеру, а тот в свою очередь обратился к модели под объекта, взял нужные данные, вернул базовому контроллеру, и когда собрал все данные с под объектов отправил в базовую модель чтобы та что-то там посчитала. И изменила данные внутри себя.

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

Добавлено через 15 минут
Вот это интересный вариант, только Громадный. :) Спасибо.

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

Ну я конечно хз что там автор планирует, но можно примерно так всё решить:

1. C1 содержит в себе М1.
2. М1 состоит из нескольких маленьких моделей SM1-SMn(SmallModel) (ну массив дочерних моделей или как-то так)
3. С1 имеет ссылки на все Дочерние контроллеры. Так же С1 подписывается на их Ивенты.
4. если надо что-то поменять по инициативе Дочернего контроллера он просто диспатчит событие (на которое подписан С1) "Контроллер поменяй модель"
5. ...
6. PROFIT

//******
З.Ы. Я бы тут диспатчил не Event а DataEvent - так как ДатаИвент может в своем теле содержать еще и строку кроме самого типа. Таким образом грамотно продумав систему сообщений можно обойтись без создания своего класса ивента.

Добавлено через 1 минуту
Публичный геттер на модель я хз. Чтоб геттером воспользоваться надо ссылку иметь, а чтоб дочерние контроллеры на родтеля ссылку имели - это уже не ок. Так что в попу публичный геттер на модель.

Dukobpa3, хм... интересный вариант, но мне непонятно кто создает SmallModels.

Например С1 создал подобъект c2 и по идеи м2 должен создавать с2, но у него нету ссылки на М1. И как правильно создавать м2 в М1?

Ты вообще весь вариант не понял:) Еще раз прочти.

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

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

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

Как еще один вариант - главный контроллер изначально создает модель с ее дочерними моделями. Потом создает пачку контроллеров, потом в эти контроллеры передает ссылки для маленьких моделей.

Добавлено через 3 минуты
Всё зависит от требований всего приложения или текущего модуля. В любом случае передавать ссылку народителя в дите - плохой вариант.

Добавлено через 5 минут
В большинстве случаев при такой структуре можно обойтись без маленьких контроллеров. А оперировать исключительно одним большим контроллером в котором будет большая модель и большая вью. Большая модель будет в себе содержать кучу маленьких моделек, а большая вью будет в себе содержать кучу маленьких вьюшек которые будут связаны с маленькими модельками. А рулить всем будет один большой контроллер.

Ну ладно, я пошел жарить попкорн

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

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

Все равно спасибо за описание, из ваших постов я понял либо оставлять как есть, либо переделать еще раз через левое ухо.

В порядке интереса. Ознакамливались ли вы с набившей в свое время оскомину темой, вынесенной в ЧАВО?

Я бы контраргументы выслушал.
Вот этот момент очень спорен на самом деле. Вообще никто никому ничего не должен. Единственное что точно не должно быть - это ссылка на родителя у дитяти.

А вот это признак неправильной архитектуры, так как, в любом случае, можно пойти, как всегда, несколькими путями:
1. SomeItemModel implements IItemModel - В этом случае еще придется подумать как дальше быть
2. SomeItemModel extends AbstractItemModel - а в этом случае в абстрактном классе модели может быть параметр type. И главному контроллеру достаточно просто знать одно имя суперкласса плюс тип модели(строковый параметр например).
3. MainModel.addItemModel() - в этом случае главная модель имеет публичный метод добавления нового итема. И тут уж точно главному контроллеру абсолютно ничего знать не нужно.

Да, с момента ее формирования.

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

Я как раз как неправильную и привожу в пример.


А вот это думаю то что мне нужно. Сейчас попробую. Спасибо.

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

Надо завести раздел "Притчи" :)

Пост сакрального смысла!
Два корня, верно?

Добавлено через 5 минут
Это же бубл-гум парабола!

А разве оффтоп не карается по закону? Я думал ты как раз модератор за этим следишь. :)

Смотря какое исчисление если действительные числа то 1, а если комплексные то 2: 2i и -2i.

Сейчас твой пост выглядит как оффтоп ) У параболы один только корень (x) в точке 0,0. Остальные корни ломятся парами.

wvxvw внёс ясность!
PS: Истинный Корень Квадратный - один, тот, что возвращается функцией sqrt и который подразумевают, говоря "корень из" и рисуя значок корня над цифрой! А "-2" - от Сотоны!

Хех. А я что сказал?

Мы отвлеклись. Продолжайте про МВЦ!

Добавлено через 1 час 24 минуты
Прошу прощения, но тема MVC настолько разнообразна, что пришлось прибегнуть к подмене тезиса.

Сорри, я не специально :) Я вообще к тому, что, я уже перевидел столько вариаций на тему, при чем, особенно таких, где человек пытаясь следовать каким-то необоснованым правилам творил неимоверные глупости свято веруя в то, что именно так и нужно. Лучше все-таки руководствоваться логикой, или, наывайте это здравым смыслом. По крайней мере есть шанс, что другие разработчики поймут то, что вы писали.

По поводу квадратных корней - ну, как бы вроде все просто, 2 и -2. Их, конечно, можно представить как комплексные числа, но в данном случае не нужно. Вот если бы это был, например, корень кубический из -27, тогда их (корней), было бы 3, и без иррациональных чисел уже никак не обойтись :)