|
|
Регистрация Восстановить пароль |
Регистрация | Задать вопрос |
Заплачу за решение |
Новые сообщения |
Сообщения за день |
Расширенный поиск |
Правила |
Всё прочитано |
|
|
Опции темы | Поиск в этой теме |
12.01.2013, 15:46 | #1 |
Форумчанин
Регистрация: 15.02.2008
Сообщений: 621
|
Концепция Model-View-ViewModel
Доброго времени суток товарищи!
Без лишней лирики, с вашего разрешения, перейду к поднимаемой проблематике. Хочу с вами обсудить на какие юниты будет правильно разбить проект при концепции MVVM?
Помог? Ну так нажми на весы!
|
12.01.2013, 17:22 | #2 |
Белик Виталий :)
Старожил
Регистрация: 23.07.2007
Сообщений: 57,097
|
Какие юниты всмысле?
I'm learning to live...
|
12.01.2013, 22:25 | #3 |
Форумчанин
Регистрация: 15.02.2008
Сообщений: 621
|
Имелось введу на какие Unit файлы. Вы пожалуйста не думайте что это ламерского формата вопрос. Это больше архитектурного плана вопрос. Т.к. на данный момент реализую проект по принципу экстремального программирования и поэтому необходима максимально граммотная архитектурная схема приложения, что бы изменения производились максимально безболезненно. Свои видения по данному вопросу я имею:
Все три класса (модель, видение, видение модели) и интерфейсы держать в одном модуле. Какие-нибудь производные вынести в другие модули. Пробовал раскидать в начале интерфейсы и классы в разные модули, НО столкнулся с проблемой зацикленных ссылок на юниты. Но хотелось бы услышать другие другие мысли по этому поводу. Для менее голословного разговора предлагаю взять тривиальную задачу списка документов и его отображения. ЗЫ возможно я конечно поспешил, и придется прибегнуть к паттерну Model-View-Presenter вместо MVVM. Этот момент я так же надеюсь разберем по ходу обсуждения.
Помог? Ну так нажми на весы!
Последний раз редактировалось SNUPY; 12.01.2013 в 22:36. |
12.01.2013, 22:46 | #4 |
Белик Виталий :)
Старожил
Регистрация: 23.07.2007
Сообщений: 57,097
|
Так ведь паттерны не располагают сведениями о разделении на модули. Это зависит от удобства разработки.
I'm learning to live...
|
12.01.2013, 22:51 | #5 |
Форумчанин
Регистрация: 15.02.2008
Сообщений: 621
|
Я вот как раз в проекции удобства разработки и пытаюсь поговорить, т.е. как вы товарищи решаете свои задачи подобного класса?
Помог? Ну так нажми на весы!
|
12.01.2013, 23:01 | #6 | |
Белик Виталий :)
Старожил
Регистрация: 23.07.2007
Сообщений: 57,097
|
Во, терь ясно.
Честно признаюсь, я может самый глупый из разработчиков, но саму структуру и связку модулей я придумываю по ходу надобности. Бывает не редко что приходится все переписывать из за тупиковой модели. И она для каждой задачи абсолютно различается. Цитата:
1) Главный модуль - контроллер 2) Модуль документов - датабулщит 2.1) Модуль архивариуса документов 2.2) Модуль пользовательских (нестандартных, добавляемых для каждого пользователя индивидуально) документов 2.3) Модуль поиска. Просто получает список документов (ссылки на них) и проведя поиск выдает контроллеру результат 3) Отображатель. Все. Больше не дробил, и кроссылки не завелись.
I'm learning to live...
|
|
12.01.2013, 23:15 | #7 |
Форумчанин
Регистрация: 15.02.2008
Сообщений: 621
|
если я правильно понял 1-ый имеет ссылки на 2-а и 3-и?
Помог? Ну так нажми на весы!
|
13.01.2013, 00:11 | #8 |
Старожил
Регистрация: 30.12.2009
Сообщений: 11,430
|
Я если изначально не могу уложить в голове весь объем работ, размах и структуру,то пишу все на обум(1 класс - 1 модуль), затем все это дело запускается и работает через пень-колоду Тогда видно, кого, кому в подчинение отдать, как и что оптимизировать.
Однако сейчас, откройте для себя UML моделирование. В делфи есть свой инструмент для этого, однако я привык пользоваться этим. А ещё есть нечто такое. Но сразу могу сказать, что, нужно иметь собственный модуль для констант и глоб. переменных, собственный для строк(resourcestrings), модуль с функциями повседневной жизни(вспомогательные) ну и конечно же нужно иметь отдельный модуль для объявления типов(и ничего кроме) и структур. Облегчают жизнь. |
13.01.2013, 00:13 | #9 | |
Белик Виталий :)
Старожил
Регистрация: 23.07.2007
Сообщений: 57,097
|
Цитата:
I'm learning to live...
|
|
13.01.2013, 10:34 | #10 |
personality
Старожил
Регистрация: 28.04.2009
Сообщений: 2,885
|
http://programmersforum.ru/showthread.php?t=224092 про циклические ссылки.
С мввм не работал, работал с мвс , писал так - контроллер знает всё о модели, вьюха не знает ничего кроме контроллера. Контроллер всем заправляет, вьюха держит у себя экземпляр контроллера, который может по-разному инстанцироваться, определяя разное поведение работы всей системы, вьюха регистрирует на контроллера свои коллбеки. Естественно, при взаимодействии с пользователем вьюха отсылает только команды(сообщения) контроллеру, который их пробивает по модели , производит всю работу и дёргает нужные колбеки вьюхи. По модулям - условно говоря для каждой сути был 1 модуль (ну сама суть бывало по нескольку состояла модулей, но для модуля другой сути - обычно всё оборачивалось в подключение 1 модуля другой сути), примерно так вьюха->контроллер->модель, т.е. вьюха знает контроллер, ибо она его инстанцирует и шлёт ему команды, а контроллер знает только модель, со вьюхой он непосредственно не общается, только колбеки дёргает, ну а модель вообще ничего не знает. Возможно , немного слабая по гибкости система, ибо у меня вьюха всегда одна, но вполне, думаю, можно раскинуть будет на много вьюх, если не сама вьюха будет инстанцировать а только хранить ссылку на контроллер, а тот будет инстанцироваться по иным условиям (сам например, на старте прилады), ну и для поддрежки сразу многих вьюх надо будет просто пул колбеков содержать от разных вьюх на одни и те же действия. Также могу предложить на мой взгляд действенный способ разрешения межмодульной осведомлённости сущностей: имеется 1 модуль абстрактных сущностей - в нём каждая абс.сущность знает о другой ввиду общего модуля, имеет ссылки на эти сущности и т.п. этот модуль подключается почти ко всем модулям конкретных сущностей - реализуем всех потомков, но друг к другу модули потомков, конечно, не подключаем. В итоге любая сущность общается с другой через абстрактный интерфейс такой сущности и никак не может и не должна знать о конкретике. Инстанцирование же конкретными классами (ссылок на потомков сущностей, с типом ссылок - предком) каждой сущности должен производить некий менеджер, который и знает всех "в лицо", он служит для управления связанностью. |
|
Похожие темы | ||||
Тема | Автор | Раздел | Ответов | Последнее сообщение |
Концепция управляемых данными приложений. | the_deer_one | Свободное общение | 6 | 25.10.2012 19:17 |
MVC (model-view-controller) | acteralex | PHP | 8 | 01.02.2012 13:46 |
Концепция реализации веб-интерфейса | Ma7 | Помощь студентам | 11 | 04.09.2011 22:48 |
Model View Дельфи 2010 | Utkin | Софт | 2 | 08.12.2010 13:52 |
С+++ концепция | sofen.ru | Софт | 13 | 03.11.2010 19:00 |