Есть дата-лэйер, представленный ef, контекстом, моделями БД. Есть сервис-лэйер, представленный

Question

Есть дата-лэйер, представленный ef, контекстом, моделями БД. Есть сервис-лэйер, представленный

сервисом, в который инжектится контекст, он оперирует моделями БД. Есть веб-лэйер, в него инжектится сервис. Правильно ли давать вебу оперировать моделями БД, или нужно завести свои и преобразовывать их при передачи к/от сервису?

#backend #dot #programming #russian

0

08.02.2018

2 ответов

20 просмотров

Roman Bukin

Обычно заводятся отдельные модели на приём и на отдачу. Помогает в этом нелёгком деле, как правило - Automapper. Так как параметры запроса, во-первых, далеко не всегда соответствуют сущностям (методы PUT/POST), а во-вторых отдавать, как правило, мы хотим тоже далеко не всё (например, на GET запрос /api/users мы не хотим отдавать хэш пароля). Делать их не слишком накладно, поэтому лично я их делаю всегда, так как когда начинаешь крутить-вертеть саму доменную модель и логику, то иногда это можно сделать не сломав внешний контракт, но при этом внутри самого приложения могут происходить значительные изменения. Так же, то что я возвращаю всегда обладает get-only свойствами (и Automapper таки может находить их по имени в конструкторе и смапить значения из соответствующих свойств), что бы не повадно было менять смапленные модельки, вернувшиеся из сервисного слоя. И если ты такое видишь в коде - то можешь смело выписать пиздюлей на ревью за такое, так как подобной логикой должен обладать сервис, а не экшон контроллера, который как правило, предельно туп (у меня 5-7 строчек обычно).

0

08.02.2018

ιπταμενο ψαρι · Accepted Answer

ιπταμενο ψαρι

Почему б и нет (если есть возможность не писать бойлерплейт, ей обязательно надо пользоваться). Обычно делают по DTO на каждый тип запроса и дальше уже дёргают сервисы с нужными данными

0

08.02.2018

170 похожих чатов

Есть дата-лэйер, представленный ef, контекстом, моделями БД. Есть сервис-лэйер, представленный

2 ответов

Похожие вопросы