Как получить доступ к данным, когда viewModel зависит от нескольких моделей - PullRequest
Новая
       14

Как получить доступ к данным, когда viewModel зависит от нескольких моделей

0 голосов
/ 20 мая 2018

Я новичок, пытающийся обернуть голову вокруг MVVM.Я пытаюсь что-то построить и не нашел ответа на вопрос, как с этим справиться:

У меня есть несколько моделей / сущностей, некоторые из которых имеют логические связи, и мне интересно, где и когда все это взятьвместе прекрасно.

Предположим, у нас есть PersonModel: 

public class PersonModel { 

public int Id {get;set;}
public string Name {get;set;}
...
}

и ClubModel: 

    public class ClubModel {

    public int Id {get;set;}
    public string Name {get;set;}
    ...}

И у нас есть MembershipModel (человек может иметь несколько членств в Клубе): 

public class MembershipModel {

public int Id {get;set;}
public PersonId {get;set;}
public ClubId {get;set;}}

Все эти модели хранятся где-то, и модели сохраняются "как в" в этом хранилище данных.

Предположим, у нас есть отдельные репозитории для каждой из этих моделей, которыепредоставляет стандартные операции CRUD.

Теперь я хочу создать ViewModel для управления всеми людьми, например, переименование, добавление членства и т. д. -> PersonMangementViewModel.

Для того, чтобы красиво связать человека ссо всеми его свойствами и членством я бы также создал модель PersonView (?), которую можно использовать в PersonManagementViewModel.Он может содержать, например, просмотр соответствующих свойств, а также членство: 

public class PersonViewModel : PersonModel {

public Color BkgnColor {get return SomeLogic();}
public IEnumberable<MembershipModel> {get;set;}
...
}

Мой вопрос здесь: как бы я поступил, чтобы получить информацию о членстве в PersionViewModel?Конечно, я мог бы создать экземпляр MemberShipRepo непосредственно в PersionViewModel, но это кажется нехорошо, особенно если у вас много людей.Я также мог бы создать все репозитории в PersonManagementViewModel, а затем передать ссылки в PersonViewModel.

Или имеет смысл создать другой слой (например, слой «сервис»), который возвращает в первую очередь PersonViewModel, поэтому использует индивидуальныйрепозитории и вызывается из PersonManagementViewModel (таким образом, снимая с него бремя и позволяя повторно использовать сервис в другом месте)?

Рад, что указал на концептуальные ошибки или какое-то дальнейшее чтение.Спасибо

1 Ответ

0 голосов
/ 21 мая 2018

Я полагаю, вы создаете отдельную модель для каждой таблицы.Не имеет значения, но ваши модели фрагментированы.Вы можете объединить связанные данные, используя Aggregate Root и Repository для Aggregate root, а не для модели.Эта концепция обсуждается в DDD.Но, как вы сказали, вы новичок в MVVM, уже есть чему поучиться.Вовлечение DDD на этом этапе только усложнит ситуацию.

Если вы решите оставить все как есть, лучше и быстрее я могу предположить, что вы делаете сейчас.Получить экземпляр модели из хранилища данных в View Model (или независимо от вашего местоположения) и каким-либо образом отобразить карту.Такие инструменты, как Automapper, хороши, но они не подходят для каждой ситуации.Не стесняйтесь наносить карту вручную, если это необходимо.Вы также можете использовать смешанный подход (Automapper + map by hand), чтобы упростить задачу.

Об уровне обслуживания, конечно ... почему бы и нет.Полностью зависит от вас.Если используется, этот слой обычно содержит вашу бизнес-логику, отображение, форматирование данных, проверки и т. Д. Опять же, каждый из этих вопросов зависит от вас.

Мои предложения:

  • Сначала сфокусируйтесь на целях вашего бизнеса.
  • Шаблоны проектирования хороши и полезны.Это выдержка многих исключительно способных разработчиков для решения конкретной проблемы.Используй их.Но не стоит излишне придерживаться этого.Прочитайте выше предложение.Короче говоря, избегайте чрезмерного проектирования.Шаблоны проектирования создаются для решения конкретной проблемы.Если у вас нет этой проблемы, не путайте ваш код с ненужным шаблоном.
  • Прочтите об объединенном корне, DDD, репозитории и т. Д.
  • Старайтесь изо всех сил избегать универсального репозитория.
...