Каждому своё.

Да, в этом есть резон, выносить парсер отдельно от модели. Я делал разбор в самой модели, это не очень удобно.

Увидел тут мельком, речь зашла о ветвлении Моделей и Контроллеров. Я как раз до этого в своём проекте дошёл. Вот смотрите, есть игра, в ней у героя инвентарь. Его функционирование обеспечивается своей персональной триадой MVC, верно. Когда пользователь жмёт кнопку инвентаря, это событие слушает главная Вью и посылает событие в главный Контроллер. Главный Контроллер создаёт дочерний Контроллер инвентаря, который в свою очередь создаёт Модель и Вью инвентаря. Дальше все манипуляции обрабатываются дочерней MVC, и только событие на закрытие остаётся за главным Контроллером, который, получив его, свернёт всю лавочку и даст команду главной Модели продолжать.
Верно я всё написал?

Контроллеры создает контроллер. Модели — модель. Вьюхи плодятся во вьюхе.
Ко всем этим дочерним элементам есть доступ по геттеру, например.
Триада создается путем создания нового контроллера, который всегда имеет в аргументах как минимум две ссылки: необходимые ему для работы модель и вью.
Есть только один контроллер, который создаем модель и вью — это MainController. В нем создаются MainModel и MainView. Больше ни в одном контроллере модели и вьюхи не создаются. Они подаются в конструктор (или метод-инициализатор).

Вот кстати, вопрос терминологии:является ли предложенная схема HMVC?Потому как картинка на вики намекает, что ветвление происходит внутри фасада.Хотя смысл в обоих подходах идентичен имхо.

А ты сам как думаешь?

думаю,что нет,но древовидность обоих заставляет сомневаться.

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

Модель не нужно создавать при нажатии на кнопку инвентаря. Она просто всегда есть в полном объеме. Когда создаем (показаваем) инвентарь, то передаем вьюхе нужную часть модели (коллекцию предметов). Контроллером и вьюхой списка выступает data driven компонент, например, List.

Самое главное, что модель одна и она глобальна.

Друзья, вновь меня терзают сомнения в части MVC. Исходные такие.

В Модели в качестве идентификаторов у меня используются строковые значения. Они объявляются публичными статическими константами и затем присваиваются разным нечисловым свойствам. Возможно, это не оптимально с т.з. использования ресурсов, но очень удобно при отладке, так как такие штуки можно выводить в trace() и сразу понимать, что происходит. При этом я использую те же идентификаторы при обращении к классам пакета language, подбирающим слова и фразы на нужном языке. Это уже работа Вью.

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

Просьба прокомментировать. Спасибо.