C# Как правильно организовать код, с преобразованием моделей?

Question

[Daeamon]

Здравствуйте, имеется модель материала Article:

public partial class Article{
        public DBArticle(): base()
        {
            this.Category = 0;
            this.AuthorID = 0;
            this.AuthorPseudo = 0;
            this.YandexGenre = 1;
            this.GoogleGenre = 1;
            this.MaterialType = 1;
            this.ArticleThemeID = 0;
            this.ShowImage = true;
            this.Featured = false;
            this.Hits = 0;
            this.ArticleStyle = 0;
        }
    
        public int ID { get; set; }
        public string Title { get; set; }
        public string Alias { get; set; }
        public string Lead { get; set; }
        public string Content { get; set; }
        public short State { get; set; }
        public string Image { get; set; }
        public int Category { get; set; }
        public string MetaTitle { get; set; }
        public string MetaDescription { get; set; }
        public string MetaKey { get; set; }
        public string Robots { get; set; }
        public System.DateTime Created { get; set; }
        public int AuthorID { get; set; }
        public int AuthorPseudo { get; set; }
        public short YandexGenre { get; set; }
        public short GoogleGenre { get; set; }
        public short MaterialType { get; set; }
        public int ArticleThemeID { get; set; }
        public bool ShowImage { get; set; }
        public bool Featured { get; set; }
        public int Hits { get; set; }
        public short ArticleStyle { get; set; }
    }

Для редактирования в админке данного материала я создал дополнительную модель FrontEndArticle

public partial class EditorArticle:Article{
        public ArticleModel(Article doc)
        {
            var mapper = new MapperConfiguration(cfg => cfg.CreateMap<Article, ArticleModel>()).CreateMapper();
            mapper.Map(doc,this);
        }
        public List<SelectListItem> Categories { get; set; }
        public List<SelectListItem> Authors { get; set; }
        public List<SelectListItem> AuthorsPseudo { get; set; }
        public List<Tag> Tags { get; set; }
        public List<ArticleTheme> ArticleThemes { get; set; }
        public List<GalleryWithRows> Galleries { get; set; }
    }

Тут списки:
Categories: категорий
Authors: авторов
AuthorsPseudo : псевдонимов авторов
Tags : тегов
ArticleThemes : тем материалов
Galleries: галлерей

Соответственно для формирования такой модели у меня есть отдельная функция в мусоросборочном классе(так как я не совсем уверен куда это правильно поместить) которая в свою очередь и добывает/формирует все эти списки.

Так же есть еще модель на отображения на самом сайте.

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

Пожалуйста подскажите как вы организовываете подобное в своем коде и как это сделать правильно? Где должны быть функции для получения такой расширенной модели? Нужна ли вообще такая модель? Как избавиться от одного класса хелпера со всеми подряд функциями(от формирования подобных моделей до формирования строк md5,сохранения файлов и т.д.).

Заранее спасибо)

Answer 1

[Евгений]

Модели предпочитаю делить на доменные(то, что мапится к БД) и модели представления(то, что нужно отдать клиенту). Реляционная модель данных в большинстве случаев не кореллирует с моделью представления(в вашем случае, например, списки категорий и пр.)

Наследование же представления от домена, на мой взгляд, абсолютно имеет место быть для систем без сложной бизнес-логики (там, где просто CRUD - можно вообще без моделей представления обойтись); в ином случае можно закончить тем, что будет несколько уровней наследования в погоне за требуемым классом. И каждое изменение такого класса(особенно, если он родительский) может стать головной болью.

Обычно, использую такую декомпозицию слоев приложения:
View -> Controller <-Service <- Repository <- Database

Уровень Repository оперирует доменом, уровень Service оперирует как доменом, так и представлением, уровень Controller - только представлением. Соответсвенно, в уровне сервисов и производится преобразование домена в представление.

Comments

[Daeamon]

т.е. в случаях когда модель для редактирования нужного нам объекта весьма отличается от основной модели(как модель EditArticle отличается от Article теми же списками) то лучше вообще не делать такую модель а прокинуть в View все нужные нам списки посредством ViewBag?

[Евгений]

Daeamon, опять же, зависит от контекста задачи(что за приложение, бизнес-логика). На этот вопрос нельзя ответить однозначно.

Лично я стараюсь вообще не использовать ViewBag и ViewData при оперировании моделями. Они нетипизированные, ошибок во время компиляции не увидеть - слишком опасно использовать.

Я бы создал отдельную модель представления для статьи, например, ArticleViewModel, которую наполнил бы необходимыми данными для отображения элемента. От нее бы унаследовался моделью ArticleEditViewModel, где добавил бы поля для списков, которыми требуется заполнить DropDown-ы для изменения статьи.

При этом, ArticleViewModel - это класс, никоим образом не зависящий от доменной модели Article. Это просто базовый класс для модели представления статьи. Где-то на уровне сервисов происходит маппинг домена, который приходит из репозитория, в модель представления, который отдается сервисом в контроллер.

[Daeamon]

т.е. я почти правильно выбрал решение единственное, реализация пока хромает)))
А почему не стоит наследовать ArticleViewModel от Article? Это же весьма удобно))) И маппер автоматически все поля заполнит, конечно будут и лишние поля но это не настолько ужасно))

[Евгений]

Daeamon, опять же, можно и не разделять на модели домена и представления. It's up to you. Просто доменная модель, являющаяся по сути репликацией реляционной модели БД, зачастую всегда не подходит для передачи данных на клиент. Опять же где-то надо ассоциированный список вывести, где-то подтянуть еще какие-то данные.

При такой концепции в качестве плюса получим разделение обязанностей, большую гибкость при обработке и тестировании, но и большее количетсво кода - это да. Тут уже решать Вам.

И маппер автоматически

Кстати, маппер прекрасно отработает, когда есть два друг с другом не связанных класса. Вовсе не обязательно его в конструкторе наследника запускать.

[Daeamon]

Евгений, В идеале было бы неплохо посмотреть на исходники какого ни будь годного проекта(полностью соответсвующего методологии S.C.R.U.M.) на asp.net mvc с использованием различных паттернов проектирования(того же DI), запросами к базам, как раз с решением проблемы описанной выше и т.д.
ЗЫ: спасибо за помощь)

[asdz]

Daeamon, наверное SOLID, не S.C.R.U.M. ))