Как “высушить” атрибуты C# в Моделях и ViewModels?

Как сказал LukLed, вы можете создать базовый класс, от которого наследуются модели View и Edit, или вы также можете просто получить одну модель представления из Другие. Во многих приложениях модель редактирования в основном такая же, как и у View, плюс некоторые дополнительные вещи (например, списки выбора), поэтому может иметь смысл вывести модель редактирования из модели View.

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

Другой вариант - просто охватить отдельные модели. Я все о том, чтобы логика была СУХОЙ, но меня меньше беспокоят несколько избыточных свойств в моих DTO (особенно в проектах, использующих генерацию кода для генерации 90% моделей представления для меня).

Первое, что я заметил - у вас есть 2 модели просмотра. Подробности см. В моем ответе здесь .

Другие вещи, которые приходят в голову, уже упоминались (классический подход к применению DRY - наследование и соглашения).

Думаю, я был слишком расплывчатым. Моя идея состоит в том, чтобы создать модель представления для каждой модели предметной области, а затем - объединить их в модели представления, соответствующие конкретному представлению. В вашем случае: =>

public class FooViewModel {
  strange attributes everywhere tralalala
  firstname,lastname,bar,fizz,buzz
}

public class FooDetailsViewModel {
   public FooViewModel Foo {get;set;}
   some additional bull**** if needed
}

public class FooEditViewModel {
   public FooViewModel Foo {get;set;}
   some additional bull**** if needed
}

Это позволяет нам создавать более сложные модели представлений (для каждого представления) =>

public class ComplexViewModel {
    public PaginationInfo Pagination {get;set;}
    public FooViewModel Foo {get;set;}
    public BarViewModel Bar {get;set;}
    public HttpContext lol {get;set;}
}

Вы можете найти этот мой полезным вопросом.

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

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

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

Объявить базовую модель, наследовать и добавить другие свойства:

public class BaseFooViewModel
{
    [DisplayName("First Name")]
    public string FirstName { get; set; }

    [DisplayName("Last Name")]
    public string LastName { get; set; }

    [DisplayName("Email Address")]
    [DataType("EmailAddress")]
    public string EmailAddress { get; set; }
}

public class FooDisplayViewModel : BaseFooViewModel
{
    [DisplayName("ID Number")]
    public int Id { get; set; }
}

public class FooEditViewModel : BaseFooViewModel

ИЗМЕНИТЬ

О категориях. Не следует редактировать модель представления, имеющую общедоступную строку CategoryName {get; набор; } и public List Категории {get; набор; } вместо SelectList? Таким образом вы можете разместить публичную строку CategoryName {get; набор; } в базовом классе и оставьте DRY. Режим редактирования расширяет возможности класса, добавляя List .

Эти отображаемые имена (значения), возможно, могут отображаться в другом статическом классе с большим количеством константных полей. Не избавит вас от множества экземпляров DisplayNameAttribute, но позволит быстро и легко изменить имя. Очевидно, это бесполезно для других мета-атрибутов.

Если бы я сказал своей команде, что им пришлось бы создавать новую модель для каждой маленькой перестановки одних и тех же данных (и впоследствии писать для них определения автомапперов), они восстали бы и линчевали меня. Я бы предпочел моделировать метаданные, которые были в некоторой степени осведомлены об использовании. Например, создание обязательного атрибута свойств вступит в силу только в сценарии «Добавить» (Model == null). Тем более, что я бы даже не стал писать два представления для добавления / редактирования. У меня было бы одно представление для обработки обоих из них, и если бы я начал использовать разные классы моделей, у меня возникли бы проблемы с объявлением моего родительского класса ... бит ... ViewPage.