Что вы делаете, когда у вас есть богатые модели? - PullRequest
Новая
       33

Что вы делаете, когда у вас есть богатые модели?

4 голосов
/ 06 октября 2011

Я работаю с существующим кодом в проекте, который имеет повсеместно богатые модели (вместо POCO). В принципе, есть ли хороший способ смешать богатые модели и модели моделей без повторения кода?

  • Богатые модели имеют проверку данных. Есть ли простой способ использовать их с ViewModels?

Пример: 

public class PersonViewModel : INotifyPropertyChanged, IDataErrorInfo
{
    private Person _person;

    [Required] //This seems redundent...
    public String FirstName { ... }
}

public class Person
{
    [Required]
    public String FirstName { ... }
}

Это всего лишь один пример ... по сути, если у вас есть Rich Model, есть ли способ воспользоваться этим, поддерживая MVVM и избегая избыточного кода? Мне бы очень хотелось, чтобы мои Модели не были связаны с каким-либо контекстом данных или полностью отображались в ViewModel.

Например: 

public class PersonViewModel : INotifyPropertyChanged, IDataErrorInfo
{
    private Person _person;

    //This seems like a bad thing to do...
    public Person ThePerson { get { return _person; } }
}

Ответы [ 3 ]

3 голосов
/ 08 октября 2011

Это что-то вроде классического вопроса.

Если вы «загрязняете» свои классы модели интерфейсами и атрибутами, специфичными для уровня представления, вы получаете эффективность, имея только одну версию любой логической модели, но теряете способность эволюции представления и бизнес-модели развиваться независимо..

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

С точки зрения теории и для более сложных систем, я бы порекомендовал последнее.Если ваша система относительно проста (например, CRUD), и вам не нужно, чтобы два типа моделей развивались независимо, вы, вероятно, достаточно уверены в первом.

Очевидно, что эти два метода невзаимоисключающие, и принятие решения на основе экрана не случайно.

1 голос
/ 08 октября 2011

Я никогда не видел ничего плохого в том, чтобы выставлять модели целиком из ViewModel для просмотра. Я знаю, что это не подход «MVVM-Purist», но он простой, быстрый и хорошо работает.

Но я понимаю, что оба метода одинаково допустимы, и обычно для очень большой кодовой базы такое разделение между Model и ViewModel облегчает жизнь в долгосрочной перспективе. В таком случае, почему бы вашей проверке ViewModel не вернуть ваше ModelValidation? Это не так красиво, как использование DataAnnotations, но вы не будете создавать проверку в нескольких местах.

Например, я часто использую что-то вроде этого: 

public string GetValidationError(string propertyName)
{
    string s = null;

    switch (propertyName)
    {
        case "FirstName":
        case "LastName":
            s = Person.GetValidationError(propertyName);
            break;
    }

    return s;
}

string IDataErrorInfo.this[string propertyName]
{
    get { return this.GetValidationError(propertyName); }
}
1 голос
/ 06 октября 2011

Одна из идей MVVM состоит в том, чтобы отделить уровень представления от уровня данных. Это дает вам возможность изменять данные, с которыми работает уровень представления, без изменения данных уровня данных.

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

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

public class PersonViewModel : INotifyPropertyChanged, IDataErrorInfo
{
    private Person _person;

    [Required] //This seems redundent...
    public ValueViewModel<String> FirstName { ... }
}

Используя этот шаблон, вашей модели не нужно реализовывать интерфейс INotifyPropertyChanged, который снова отделяет ваш уровень представления от уровня данных.

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

...