Показать сообщение отдельно
Старый 23.12.2012, 17:44
Wolsh вне форума Посмотреть профиль Отправить личное сообщение для Wolsh Найти все сообщения от Wolsh
  № 4  
Ответить с цитированием
Wolsh
Нуб нубам
 
Аватар для Wolsh

модератор форума
Регистрация: Jan 2006
Адрес: Бердск, НСО
Сообщений: 6,445
Цитата:
Где в users будет какой нибудь класс менеджер для работы со списком.
Ага. UsersModel называется.
Исторически сложилось два основных подхода к роли Модели. Один из них — Модель как свалка для хранения всего и вся, а логика приложения пораспихана по ТТУК (Толстые Тупые Уродливые Контроллеры). Это, по всей видимости, то что Вы имеете сейчас. Контроллер как бы логический класс, хранящий свой массив данных не под собственным матрасом, а в банке у Модели.
Второй подход (классический MVC) — Модель является не базой данных, а моделью состояния приложения, и содержит в себе всю логику работы с данными. В этом варианте нет места модели как сторожу свалки со свистком. Это то, к чему Вы подсознательно стремитесь. Но это не значит, что Тупой Толстой Уродливой должна быть Модель. Модель может быть композитной. Модели-дети должны быть четко известны главной фасадной модели. Им необязательно пуляться событиями в свою маму, если мама исполняет роль фасада. То есть дети могут получать свои детские сообщения от своих детских контроллеров и либо диспатчить события изменения своим детским вьюхам (по сути просто несколько параллельных MVC), либо вызывать диспатч из модели-фасада (больше порядка / меньше хаоса). Просто не рассматривайте Модель как один единственный класс. Это может быть целый самостоятельный паттерн, одним классом представленный только для слушателей. Просто.. если контроллер ДУМАЕТ, что ему делать с новыми данными, каким моделям-детям их раздавать и т.п., он становится Толстым и Уродливым, ему надо знать слишком много о Модели и о значении этих данных. Контроллер должен не более чем передать по назначению важные действия юзера во вьюхе. Если эти действия интересуют только какой-то один логический блок модели, то лучше именно эту под-модель и передать данному контроллеру для общения сразу при инициализации. Здесь весь смысл в том чтобы сместить логику из контроллеров в модельки — потому что моделям проще обмениваться расчетными данными между собой в своем семейном болоте, чем контроллерам, которые де-юре ничего друг о друге не знают и поэтому сколько-нибудь приличную логику обеспечить не могут (Тупые).
__________________
Reality.getBounds(this);