Форум программистов
 

Восстановите пароль или Зарегистрируйтесь на форуме, о проблемах и с заказом рекламы пишите сюда - alarforum@yandex.ru, проверяйте папку спам!

Вернуться   Форум программистов > Delphi программирование > Общие вопросы Delphi
Регистрация

Восстановить пароль
Повторная активизация e-mail

Купить рекламу на форуме - 42 тыс руб за месяц

Ответ
 
Опции темы Поиск в этой теме
Старый 12.01.2013, 15:46   #1
SNUPY
Форумчанин
 
Регистрация: 15.02.2008
Сообщений: 621
Вопрос Концепция Model-View-ViewModel

Доброго времени суток товарищи!
Без лишней лирики, с вашего разрешения, перейду к поднимаемой проблематике. Хочу с вами обсудить на какие юниты будет правильно разбить проект при концепции MVVM?
Помог? Ну так нажми на весы!
SNUPY вне форума Ответить с цитированием
Старый 12.01.2013, 17:22   #2
Stilet
Белик Виталий :)
Старожил
 
Аватар для Stilet
 
Регистрация: 23.07.2007
Сообщений: 57,792
По умолчанию

Какие юниты всмысле?
I'm learning to live...
Stilet вне форума Ответить с цитированием
Старый 12.01.2013, 22:25   #3
SNUPY
Форумчанин
 
Регистрация: 15.02.2008
Сообщений: 621
По умолчанию

Имелось введу на какие Unit файлы. Вы пожалуйста не думайте что это ламерского формата вопрос. Это больше архитектурного плана вопрос. Т.к. на данный момент реализую проект по принципу экстремального программирования и поэтому необходима максимально граммотная архитектурная схема приложения, что бы изменения производились максимально безболезненно. Свои видения по данному вопросу я имею:
Все три класса (модель, видение, видение модели) и интерфейсы держать в одном модуле. Какие-нибудь производные вынести в другие модули. Пробовал раскидать в начале интерфейсы и классы в разные модули, НО столкнулся с проблемой зацикленных ссылок на юниты.

Но хотелось бы услышать другие другие мысли по этому поводу.

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

ЗЫ возможно я конечно поспешил, и придется прибегнуть к паттерну Model-View-Presenter вместо MVVM. Этот момент я так же надеюсь разберем по ходу обсуждения.
Помог? Ну так нажми на весы!

Последний раз редактировалось SNUPY; 12.01.2013 в 22:36.
SNUPY вне форума Ответить с цитированием
Старый 12.01.2013, 22:46   #4
Stilet
Белик Виталий :)
Старожил
 
Аватар для Stilet
 
Регистрация: 23.07.2007
Сообщений: 57,792
По умолчанию

Так ведь паттерны не располагают сведениями о разделении на модули. Это зависит от удобства разработки.
I'm learning to live...
Stilet вне форума Ответить с цитированием
Старый 12.01.2013, 22:51   #5
SNUPY
Форумчанин
 
Регистрация: 15.02.2008
Сообщений: 621
По умолчанию

Я вот как раз в проекции удобства разработки и пытаюсь поговорить, т.е. как вы товарищи решаете свои задачи подобного класса?
Помог? Ну так нажми на весы!
SNUPY вне форума Ответить с цитированием
Старый 12.01.2013, 23:01   #6
Stilet
Белик Виталий :)
Старожил
 
Аватар для Stilet
 
Регистрация: 23.07.2007
Сообщений: 57,792
По умолчанию

Во, терь ясно.
Честно признаюсь, я может самый глупый из разработчиков, но саму структуру и связку модулей я придумываю по ходу надобности. Бывает не редко что приходится все переписывать из за тупиковой модели. И она для каждой задачи абсолютно различается.
Цитата:
предлагаю взять тривиальную задачу списка документов и его отображения.
Ну вот я делал примерно так:
1) Главный модуль - контроллер
2) Модуль документов - датабулщит
2.1) Модуль архивариуса документов
2.2) Модуль пользовательских (нестандартных, добавляемых для каждого пользователя индивидуально) документов
2.3) Модуль поиска. Просто получает список документов (ссылки на них) и проведя поиск выдает контроллеру результат
3) Отображатель.

Все. Больше не дробил, и кроссылки не завелись.
I'm learning to live...
Stilet вне форума Ответить с цитированием
Старый 12.01.2013, 23:15   #7
SNUPY
Форумчанин
 
Регистрация: 15.02.2008
Сообщений: 621
По умолчанию

если я правильно понял 1-ый имеет ссылки на 2-а и 3-и?
Помог? Ну так нажми на весы!
SNUPY вне форума Ответить с цитированием
Старый 13.01.2013, 00:11   #8
Человек_Борща
Старожил
 
Аватар для Человек_Борща
 
Регистрация: 30.12.2009
Сообщений: 11,442
По умолчанию

Я если изначально не могу уложить в голове весь объем работ, размах и структуру,то пишу все на обум(1 класс - 1 модуль), затем все это дело запускается и работает через пень-колоду Тогда видно, кого, кому в подчинение отдать, как и что оптимизировать.

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

А ещё есть нечто такое.

Но сразу могу сказать, что, нужно иметь собственный модуль для констант и глоб. переменных, собственный для строк(resourcestrings), модуль с функциями повседневной жизни(вспомогательные) ну и конечно же нужно иметь отдельный модуль для объявления типов(и ничего кроме) и структур.
Облегчают жизнь.
Человек_Борща вне форума Ответить с цитированием
Старый 13.01.2013, 00:13   #9
Stilet
Белик Виталий :)
Старожил
 
Аватар для Stilet
 
Регистрация: 23.07.2007
Сообщений: 57,792
По умолчанию

Цитата:
если я правильно понял 1-ый имеет ссылки на 2-а и 3-и?
Да. один ко многим.
I'm learning to live...
Stilet вне форума Ответить с цитированием
Старый 13.01.2013, 10:34   #10
phomm
personality
Старожил
 
Аватар для phomm
 
Регистрация: 28.04.2009
Сообщений: 2,876
По умолчанию

http://programmersforum.ru/showthread.php?t=224092 про циклические ссылки.

С мввм не работал, работал с мвс , писал так - контроллер знает всё о модели, вьюха не знает ничего кроме контроллера. Контроллер всем заправляет, вьюха держит у себя экземпляр контроллера, который может по-разному инстанцироваться, определяя разное поведение работы всей системы, вьюха регистрирует на контроллера свои коллбеки. Естественно, при взаимодействии с пользователем вьюха отсылает только команды(сообщения) контроллеру, который их пробивает по модели , производит всю работу и дёргает нужные колбеки вьюхи.

По модулям - условно говоря для каждой сути был 1 модуль (ну сама суть бывало по нескольку состояла модулей, но для модуля другой сути - обычно всё оборачивалось в подключение 1 модуля другой сути), примерно так вьюха->контроллер->модель, т.е. вьюха знает контроллер, ибо она его инстанцирует и шлёт ему команды, а контроллер знает только модель, со вьюхой он непосредственно не общается, только колбеки дёргает, ну а модель вообще ничего не знает.
Возможно , немного слабая по гибкости система, ибо у меня вьюха всегда одна, но вполне, думаю, можно раскинуть будет на много вьюх, если не сама вьюха будет инстанцировать а только хранить ссылку на контроллер, а тот будет инстанцироваться по иным условиям (сам например, на старте прилады), ну и для поддрежки сразу многих вьюх надо будет просто пул колбеков содержать от разных вьюх на одни и те же действия.

Также могу предложить на мой взгляд действенный способ разрешения межмодульной осведомлённости сущностей: имеется 1 модуль абстрактных сущностей - в нём каждая абс.сущность знает о другой ввиду общего модуля, имеет ссылки на эти сущности и т.п. этот модуль подключается почти ко всем модулям конкретных сущностей - реализуем всех потомков, но друг к другу модули потомков, конечно, не подключаем. В итоге любая сущность общается с другой через абстрактный интерфейс такой сущности и никак не может и не должна знать о конкретике. Инстанцирование же конкретными классами (ссылок на потомков сущностей, с типом ссылок - предком) каждой сущности должен производить некий менеджер, который и знает всех "в лицо", он служит для управления связанностью.
phomm вне форума Ответить с цитированием
Ответ


Купить рекламу на форуме - 42 тыс руб за месяц

Опции темы Поиск в этой теме
Поиск в этой теме:

Расширенный поиск


Похожие темы
Тема Автор Раздел Ответов Последнее сообщение
Концепция управляемых данными приложений. 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