Нужна ли прослойка между Entity Framework и сайтом?

Question

[KLUBS]

Здравствуйте!

Помогите, пожалуйста, разобраться. Нужна ли дополнительная прослойка из модели между Entity Framework и контроллером который работает со слоем данных. Т.е. вижу 2 варианта:

1.

Есть таблица dbUsers в базе. В EF создаются классы dbUsers. Неким образом создается класс User. Слой данных работает с объектами EF а пользователю (контроллеру) отдает красивые чистые объекты класса User без лишней информации.

2.
Есть таблица dbUsers в базе. В EF создаются классы dbUsers. Слой данных напрямую работает с этими объектам и передает их в контроллер. Т.е. контроллер работает с объектами типа dbUsers…

Подскажите, как правильно и почему?

Answer 1

[lair]

Пункт 0: используйте EF CodeFirst или POCO templates, тогда у вас будут «чистые классы» in the first place.
Пункт 1: все нижесказанное верно до тех пор, пока у вас контроллер работает напрямую с DAL, а не со слоем бизнес-логики или сервисов.

Есть таблица dbUsers в базе. В EF создаются классы dbUsers. Неким образом создается класс User. Слой данных работает с объектами EF а пользователю (контроллеру) отдает красивые чистые объекты класса User без лишней информации.

Это лишняя прослойка.

Есть таблица dbUsers в базе. В EF создаются классы dbUsers. Слой данных напрямую работает с этими объектам и передает их в контроллер. Т.е. контроллер работает с объектами типа dbUsers…

Это вполне нормально.

Answer 2

[SychevIgor]

С точки зрения архитектурных концепций и феншуя должна быть некоторая прослойка уже просто потому, что контроллеру нужна view model а она отличается от того что есть просто model. пример нужно сделать pager… те у нас должна появиться view model с массивом этих объектов(реально все таки если база большая не совсем массив или список но да ладно) и номер страницы а это уже извиняюсь не то что в базе хранится…
тут уже контекст веб приложения есть некоторый о котором база и model данных не обязаны знать

А с точки зрения быстрой разработки можно и на прямую делать и нарушать все концепции mvc и прочее. Ну и если вы делаете простую админку на select update delete insert то там тоже мне кажется все болт клали на это

Comments

[lair]

С точки зрения архитектурных концепций и феншуя должна быть некоторая прослойка уже просто потому, что контроллеру нужна view model а она отличается от того что есть просто model

Это неверно. Viewmodel должна быть между контроллером и представлением. И как раз контроллер ее и формирует. А вот откуда он берет данные — его личное дело.

[SychevIgor]

Согласен. фигню сморозил ViewModel нужна View именно

Answer 3

[ganouver]

Вот здесь ViewModel и Domain Model: Границы ответственности все довольно внятно расписано. Достоинства и недостатки каждого подхода.

Comments

[lair]

И вам тоже повторю: то, с чем работает контроллер — это не viewmodel. Viewmodel — это то, что контроллер отдаст представлению.

Answer 4

[FanKiLL]

Давно не пишу на asp.net mvc но в своё время использовал ViewModel.
К примеру у вас есть класс User у которого кроме прочих переменных есть переменная active которое может быть true/false, тобишь активный юзер или нет, допустим у вас есть форма регистрации юзера, но вы не хотите светить эту переменную. Использовать модель User не безопасно, так как это поле всё равно можно будет заполнить и при мапинге формы на модель это переменная заполнится, есть два решения.
1)public ActionResult registration([Bind(Exclude = «active»)] User model)
Так при мапинге данных формы на модель поле active проигнорируется.
2)public ActionResult registration(UserViewModel model)
UserViewModel будет точно такая же как и User класс, кроме поля active, таким образом поле active из формы вообще никогда не прийдёт.

Повторюсь, я давно не писал на asp.net mvc, так что может кто что дополнит или поправит.