Как избежать множественного создания классов в c# web api?

Question

[stcmd04236]

Добрый день! Есть экспериментальный проект на aspnet web api. ORM EF6. К примеру есть класс Order, OrderView, OrderDataBindingModel. Order это класс который используется в EF. OrderView для создания ответа клиенту. OrderDataBindingModel для получения данных от клиента. Разница класса Order и OrderView лишь в полях т.е. некоторые поля отсутствует в OrderView. А OrderDataBindingModel отличается с тем что в них написаны правила DataAnnotations для проверки валидности данных которые получены от клиента. Для каждой сущности придется создавать по три класса в простейших ситуациях.
Как можно избежать от множественного создания классов? Про паттернах программирования прочитал но не знаю как применит в этом случае.

Answer 1

[eRKa]

Вообще у Вас все правильно. Есть слой моделей, которые являются сущностями, есть слой моделей, которые для отображения данных, есть слой dto моделей. У меня в проектах тоже всегда так. Зря Вы думаете, что плодите их, они находятся в разных слоях (модулях), можете считать их разными доменными моделями. Для больших и сложных проектов, это оправдано. И хоть все классы со стороны могут показаться одинаковыми, но они разные, т.к. относятся к разным доменным моделям и выполняют разную функцию.

Если у Вас проект небольшой, то можно было обойтись и одним слоем для работы с ORM и не усложнять код.

Comments

[Ярослав Сиваков]

От себя добавлю:
1) пишу довольно большой проект, но стараюсь не дублировать классы без необходимости - если для view потенциально доступны все поля исходного класса (класс не содержит секурных данных типа паролей, которые не должны быть видны всем пользователям), то оставляю один общий класс на все случаи;
2) для перекидывания данных между похожими классами стоит научиться использовать спец. штуки типа AutoMapper.

[eRKa]

Ярослав Сиваков, Ярик, и ты здесь)
Тут все дело в DDD подходе, который сейчас у многих на хайпе. А там даже логика формирования данных находится внутри доменной модели. В твоем случае логика формирования данных будет снаружи.
Вот есть про это дело «Domain Driven Design: профит малой кровью». Рассказывает не внятно, но в целом принцип понятен.

[stcmd04236]

eRKa проект в принципе не большой. просто хотел как то писать меньше кода ))) (может из за лени). Используя интерфейсы и наследования вроде как то сократил но все равно создаю отдельные классы точнее до сих пор мне так казалось. И в правде если их разделить точнее оказывается обязательно нужно разделить на доменные модели тогда все станет ясно. А как вы решаете однотипные операции в контроллерах? К примеру классы Order и OrderItem у которых родительский класс является CommonObject. Однотипные операции: выборка данных. К примеру нужно выбрать Order текущего пользователя со статусом !IsDeleted. А этот поле присутствует во всех класса у которых родитель CommonObject.

[stcmd04236]

Ярослав Сиваков, Да в последнем решении начал использовать такой подход.

Answer 2

[Дмитрий Еремин]

Один класс на одну сущность и репозиторий

Comments

[stcmd04236]

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