Когда можно объединить две модели представления в 1 вместо использования какой-либо формы связи viewmodel-viewmodel? - PullRequest
Новая
       12

Когда можно объединить две модели представления в 1 вместо использования какой-либо формы связи viewmodel-viewmodel?

4 голосов
/ 04 января 2012

У меня есть 2 модели просмотра, каждая из которых имеет свой вид.

первая модель представления имеет 3 свойства, отображаемые представлением: 

PolicyProvider

PolicyType

PolicyNumber

вторая модель представления имеет только 1 свойство, отображаемое ее представлением: 

TypeOfInvestmentFund

Между PolicyType и TypeOfInvestmentFund.

* 1012 существует связь 1 ко многим. Обе эти модели представлений и их представления отображаются в виде пользовательских элементов управления в родительской форме.

Доступные варианты для TypeOfInvestmentFund зависят от того, какой PolicyType выбран в другом представлении .

Для меня это похоже на эти 2модели представлений можно комбинировать, поскольку

a) они явно несколько связаны

b) элементы управления настолько малы и просты, что объединяютсяони не будут создавать сложный и неуправляемый объект.

Однако эти данные довольно не связаны;настолько мало, что пользователь все равно хотел бы, чтобы данные были видны в отдельных частях формы (и, следовательно, размещались в отдельных представлениях).

Я лично чувствую, что объединение этих двух моделей представлений и наличие двух отдельных представлений соединяются с нимотображать разные его части намного меньше, чем управлять связью между двумя объектами.

Я мог бы, однако, создавать слабосвязанные события с помощью Агрегатора событий Prism, и хотя я никогда не делал этого, вероятно, управлять им будет не так уж и много, и если держать эти две модели представлений отдельно, это сохранит разделение проблем.Более того, если позже появятся другие элементы управления, которые также нуждаются в этой информации, я не могу продолжать поглощать их, поэтому запуск агрегатора событий на этом этапе предотвратит доработку, поскольку события будут доступны для подписки.Это еще больше работы, чем просто объединение моделей представлений.

Какая из этих двух «правильнее»?Я понимаю, что это суждение, но я не могу решить, поэтому я ищу мнения, которые помогут мне принять решение.

Ответы [ 3 ]

3 голосов
/ 04 января 2012

Модель представления отражает представление, а не данные

Если ваш View показывает Policy и динамический TypeOfInvestmentFund, то во всех ваших ViewModel должны быть оба этих объекта.

Лично я хотел бы, чтобы моя ViewModel выставляла модель Policy в View, и чтобы PolicyModel содержал свойства для Provider, Type, Number и InvestmentFund

Затем я мог бы использовать DataTemplates, чтобы сообщить WPF, как рисовать каждый объект. Вот пример, показывающий, как вы это сделаете: 

<DataTemplate DataType="{x:Type local:PolicyModel}">
    <StackPanel>
        <local:PolicyView />
        <ContentControl Content="{Binding InvestmentFund}" />
    </StackPanel>
</DataTemplate>

<DataTemplate DataType="{x:Type local:InvestmentFundA}">
    <local:InvestmentFundA />
</DataTemplate>

<DataTemplate DataType="{x:Type local:InvestmentFundB}">
    <local:InvestmentFundB />
</DataTemplate>

Редактировать

Если Policy и TypeOfInvestment - это два разных объекта, я бы оставил их Models отдельно и поместил бы их в один и тот же ViewModel. Models для моделирования ваших данных, а ViewModels для моделирования ваших View

1 голос
/ 04 января 2012

Я рассматриваю подобные проблемы как очень похожие на нормализацию базы данных.С одной стороны, нормализация является хорошей практикой, так как создает две отдельные модели представлений.Но в то же время известно, что определенная степень денормализации также помогает повысить производительность.

Лично я чувствую, что объединение этих двух моделей представлений и двух отдельных представлений, соединенных с ним для отображения различных его частей, намного дешевле, чем управление связью между двумя объектами.1005 *

И это утверждение говорит само за себя.Хотя объединение двух моделей представлений не может считаться «лучшей практикой», у меня возникает ощущение, что оно имеет смысл для вашего приложения (на основе упомянутых вами уровней связности и сложности).Я бы сказал, что нужно объединить их и следить за тем, как они работают.

0 голосов
/ 05 января 2012

Хорошо, спасибо за ответы.Получил кучу идей из предложения Рейчел (upvote для вас, мэм), но ни одна из них не удалась.В конце концов, руководителю проекта не понравилась идея, и он хочет, чтобы я внедрил более стандартный подход для удобства чтения и предотвращения переделки, поэтому я собираюсь перейти к корню сообщения.

Вместо Eventaggregator я просто собираюсь заставить родителя подписаться на событие PropertyChanged дочернего элемента Policy, а затем изменить свойство дочернего элемента TypeOfInvestment.

I'mкак-то обидно, что мне не удалось реализовать слияние viewmodel, поскольку оно действительно имело для меня больше смысла.

...