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

Question

Я создаю просмотр моделей для каждого экрана в моем приложении ASP.NET MVC. Я поместил всю логику для создания модели представления в класс builder . Обычно существует специальная логика для преобразования объектов данных в модели представлений, включая агрегирование, фильтрацию и сортировку. Каждому сборщику передается набор зависимостей , который представляет собой объект, содержащий свойства для каждой зависимости (репозитории, другие сборщики и т. Д.).

Проблема в том, что мои имена становятся действительно длинными. Набор зависимостей обычно имеет имя, составленное следующим образом:

вид-модель-имя + Builder + DependencySet

Представления моделей обычно имеют имена, состоящие из того, где вы сейчас находитесь, и детей. Например, моя система классифицировала определения провайдеров. Итак, чтобы показать определения провайдера в категории, у меня есть модель представления под названием:

CategoryProviderDefinitionListViewModel

Это будет выглядеть примерно так:

public sealed class CategoryProviderDefinitionListViewModel
{
    public long CategoryId { get; set; }
    public string CategoryName { get; set; }
    public ProviderDefinitionViewModel[] ProviderDefinitions { get; set; }
}

Итак, моего строителя зовут

CategoryProviderDefinitionListViewModelBuilder

Итак, мой набор зависимостей называется

CategoryProviderDefinitionListViewModelBuilderDependencySet

Это едва умещается на экране. Мои бедные пальцы устали. Кроме того, на некоторых экранах практически отображаются одни и те же данные, поэтому названия моделей их представлений практически совпадают. Когда я просматриваю свою папку, становится действительно трудно найти конкретные классы модели представления, которые я ищу.

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

Answer 1

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

Насколько я понимаю, это соглашение было принято, чтобы избежать коллизий между моделью домена и классами модели представления (например, Product vs ProductViewModel ).Однако, поскольку ваши модели представлений названы в честь экранов, очень маловероятно, что у вас будет класс с таким же именем в вашей доменной модели.На самом деле, должно быть действительно сомнительно, почему у вас есть такой класс в вашей доменной модели!:)

Итак, если вы называете свою модель вида как-то вроде ViewProduct (чтобы позволить пользователю просматривать / редактировать продукт), вам не нужно называть его ViewProductViewModel.Видишь, куда я иду?

Следовательно, ваш класс Builder можно просто назвать ViewProductBuilder вместо ViewProductViewModelBuilder .

Что касается вашего набора зависимостей, я не уверен, каково ваше обоснование этого.Но для меня это выглядит ненужным.Если у вашего компоновщика есть зависимости от других объектов, вам нужно внедрить зависимости в конструктор компоновщика, вместо того, чтобы инкапсулировать их в другой класс (DependencySet), а затем передавать их.

Если вы обнаружите, что ваш строитель слишком зависим от вещей, и это то, что вы пытаетесь скрыть за DependencySet, то это может быть признаком запаха дизайна где-то еще.Если классы и их зависимости спроектированы надлежащим образом объектно-ориентированным образом, поведение должно очень хорошо распределяться между различными классами, и ни один класс не должен зависеть от слишком многих других вещей.Таким образом, сокрытие этих N зависимостей под 1 классом (DependencySet) - это просто лечение симптомов, а не самой проблемы.

Надеюсь, эта помощь:)

Answer 2

Я предпочитаю после исправления имен ViewModel с помощью " DTO ". (Где DTO обозначает Объект Передачи Данных, т.е. объект, который ничего не делает, но содержит информацию)

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

Answer 3

Я склонен согласиться с Мошем.

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

Конечно, в вашем ведущем / контроллере у вас могут быть коллизии имен, но это может быть признаком того, что вам нужночтобы называть ваши представления более подходящими, например, не пользователь, а ViewUser / EditUser.

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