MVC, Entity. Что должен «видеть» Контроллер?

Question

[Йцу Йцуевич]

Есть типизированные классы созданные Entity. Как Controller должен ими манипулировать?

1) В модели нужно создать класс (как обёртка) с методами, которые будут изменять данные в БД

2) Контроллер знает обо всех энтити классах и может в своих методах сделать так:

var test = new TestEntity();
test.Human.Add { Name = "Иванов Иван Иванович" };

Вопрос больше философский, но я жду мнение каждого!!!

Comments

[Йцу Йцуевич]

Кстати, во втором случае модель создавать вообще не имеет смысла, модель - это Entity классы.
Противоречит ли это MVC???

Answer 1

[ArturNak]

Первый вариант, обычно для этих целей реализуется паттерн репозиторий

Comments

[Йцу Йцуевич]

спасибо!

Answer 2

[Сергей Протько]

Читаем про сервисный слой и почему контроллеры напрямую не должны руководить бизнес логикой.

Что до модели - сущности ничего не должны знать о том кто и как их где хранит. Как уже было озвучено - шаблон репозиторий. В C# с нормальными ORM проблем вроде бы нет.

Answer 3

[Razaz]

Несколько тезисов:

Начнем с того, что EntityFramework - это ORM, предоставляющий реализацию абстрактного репозитория и Unit of Work.

Сущности могут быть трех видов - модели представления, модели бизнес домена и модели специфичные для уровня хранения.

Использование EF подразумевает сокращение моделей уровня хранения до минимума. Если вы делаете специфичные модели для уровня хранения - EF вам не нужен. Берите Dapper тот же самый.

Паттерн репозиторий рекомендуется использовать для абстракции уровня хранения данных- то есть у вас может быть EntityFrameworkRepository, MongoDbRepository, FileRepository. Если же таких абстракций не нужно - то паттерн репозиторий в отрыве от EF не нужен, и более того - антипаттерн.