Почему ругают глобальный (через статический класс, например) репозиторий? Посмотрел на статью и скачал пример в этой статье. Там у Джоша Смита CustomerRepository путешествует по всем конструкторам - начиная с MainWindowViewModel, затем передаётся в AllCustomersViewModel, затем в CustomerViewModel. Мне это не нравится. Ведь всё равно ссылка идёт на один и тот же репозиторий, т. е. на один и тот же объект, так почему бы не использовать статический класс-репозиторий, который не надо никуда передавать по цепочке конструкторов, а можно вызвать в любом месте?

skyANAuser7320, очевидно, что в рамках desktop приложения пох. А вот когда такой подход в веб перенесёшь, то очень быстро поймёшь, почему ругают :)
Что, памяти жалко?

Так почему ругают?

skyANAuser7320, очевидно, что в рамках desktop приложения пох.
На десктопах не "пох", а как удобнее. Вот тебе на десктопе как удобнее - таскать с собой его через все конструкторы ("не забыть добавить параметр..."), или в любом месте иметь доступ сразу?

user7320skyANAuser7320, очевидно, что в рамках desktop приложения пох. А вот когда такой подход в веб перенесёшь, то очень быстро поймёшь, почему ругают :)
Что, памяти жалко?

Так почему ругают?
Наверное, всё же не в памяти, а в конкуренциях доступа дело, да? Ну так при равных реализациях репозитория (есть обработка конкуренций, нет обработки) что может за/против статики говорить?

skyANAuser7320пропущено...

Что, памяти жалко?

Так почему ругают?Так тексты ошибок почитай
Какие тексты ошибок? Я ещё не пользовал, вот и спрашиваю. Если бы пользовал, сам бы знал, что и почему. Я просто увидел, что таскают репозиторий, я мне это сразу показалось дико неудобным.

skyANAuser7320пропущено...

На десктопах не "пох", а как удобнее. Вот тебе на десктопе как удобнее - таскать с собой его через все конструкторы ("не забыть добавить параметр..."), или в любом месте иметь доступ сразу?На десктопе у меня Singleton, в вебе Singlecall. Один и тот же код.

ViewModel у меня ни фига не знает о репозитории.
А что с репозиторием работает? Модель?

skyANAuser7320пропущено...

А что с репозиторием работает? Модель?Domain Model.
Ну это у меня и есть модель.


Вот, нашёл что-то как-то близко ...

skyANAuser7320пропущено...

Ну это у меня и есть модель.Отлично!

А с чего вдруг возникла необходимость "таскать с собой его через все конструкторы"? Код в студию.
Я не буду постить весь код этого Джоша - там дофига , даже если обрезать. Но у него там типа иерархия вью-моделей (примерно так - чуть ниже картинка) - главное окно, потом коллекция (тоже отдельная вью-модель) вью-моделей всех заказчиков - т. е. у каждого заказчика тоже по вью-модели. И сохранение нового заказчика было реализовано во вью-модели этого самого заказчика. Выглядит это примерно так .

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

А сами заказчики у него в файле хранились.

netivanuser7320,

может у вас вопрос DI vs ServiceLocator?
Чего? У меня репозиторий.

skyANAuser7320пропущено...

А что с репозиторием работает? Модель?Domain Model.
А если у тебя модель (твоя модель домена) одна, а на неё есть несколько моделей представления. Причём эти модели представления имеют, скажем так, совпадающий и разный набор свойств. Например, в модели есть свойства




В одной модели представления свойства




а в другой





Теперь, если у тебя репозиторий работает только с доменной моделью, то возвращает он только Id и ModelType. А в каком месте должна быть логика, выбирающая, скажем, изображение Image для второй модели представления (из базы это изображение тянуть или с файла на диске - не важно)? Если запихать её в логику самой же модели представления, то получается, что репозиторий не до конца отрабатывает свою функцию - я получаю не полноценный объект из хранилища, а только его часть. Остальную часть должна инициализировать логика того представления, к которой эта часть относится.

Может, надо сделать уже два (три) репозитория? Один - для моделей, и по одному - для каждой модели представления. Тогда репозиторий для вторых моделей представления будет сам искать нужное изображение.


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

skyANAuser7320, прочитай внимательно описание шаблона репозиторий и aggregation root .
1. По второй ссылке я не понял смысл поля HistoryEntries и почему оно принадлежит типу Order, а не, скажем, Client (логично историю заказов хранить в объекте клиента, чем в конкретном заказе, нет?). В примере 4 там эта коллекция всего один раз заполняется одним элементом в методе Approve. Что, предполагается, что один и тот же заказ может быть несколько раз зааппрувлен?

2. Вообще говоря, путь построения DDD-проектов неочевиден. Скажем, по той же второй ссылке, если выполнять те же требования в тех же 5 примерах, что привёл там автор, можно по DDD построить другую иерархию классов с другим набором полей, но чтобы тоже "было всё правильно"? Я не имею ввиду простое переименование.

3. Самое главное. Я могу понять, что там что-то новое и интересное для меня написано, но я не вижу связи с тем, что я написал выше - когда одна модель и несколько моделей представления. Ты сразу о всяких доменах говоришь, а я об одной модели - об одной сущности и её представлениях. И я спросил, как организовать репозиторий, если модель простая, а в представлениях появляются дополнительные данные, которые в модели предметной области не нужны, а в представлении нужны. Кто будет грузить эти дополнительные данные - дополнительный репозиторий для конкретной модели представления, просто в конструкторе из файла картинку подгрузить или как?

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

skyANAДавай так: опиши конкретно свою задачу.
К этому могу добавить, что модель относится к приложению на сервере. Фактически, на сервере запускается приложение, работающее с чистыми моделями. Первая модель предсталения относится к редактору, а вторая - к клиентскому приложению. Для редактора достаточно показать только название объекта, а для клиентского - надо показать картинку. Для сервера же не нужны ни название, ни картинка - ему достаточно идентификатора.

Как создать репозиторий для такой конструкции? У меня сущность, фактически, разбита по трём приложениям. Если их рассматривать как три разных сущности, то нужно три репозитория.

Может, стоит переделать классы так:




?

skyANAuser7320, а хранится это как? По трём разным базам?
Хранение я пока толком не прорабатывал. Я сначала разрабатываю саму логику. Но пока предполагается, что модель хранится в текстовом файле или в БД, а картинка точно не в базе, а в виде файла. Это нужно специально, чтобы пользователю было удобно самому картинки заменять и редактировать в подходящих редакторах.

При этом картинка на сервере не хранится - серверной части приложения всё равно, что отображается клиенту. Картинка - часть клиентского приложения.

Название (DisplayName) - примерно так же, как с картинкой. Просто я название для примера привёл, а на самом деле это такой же ресурс, как и картинка - для сервера не важно, какое там название пользователю отображается.

skyANAТоже самое про Image.

Без Model DisplayName и Image имеют смысл? Или это будет название и картинка не понятно какого объекта?
Без модели не имеют. Будет название и картинка непонятно какого объекта.

user7320skyANAТоже самое про Image.

Без Model DisplayName и Image имеют смысл? Или это будет название и картинка не понятно какого объекта?
Без модели не имеют. Будет название и картинка непонятно какого объекта.
Фактически, модель и две этих модели представления объединяет идентификатор, который хранится в модели.

В качестве рекламы: у кого есть идеи на эту тему - придите и скажите.