Структурирование приложения ASP.NET MVC (Entity Framework)

У меня есть некоторые общие вопросы о шаблоне MVC и структурировании моего приложения. В моем приложении у меня есть несколько несвязанных объектов, которыми я буду управлять. В большинстве случаев сущность может быть более одной таблицы базы данных.Структурирование приложения ASP.NET MVC (Entity Framework)

Например, приложение может управлять людьми и фруктами. Между людьми и фруктами нет никакой связи.

Сущность личности состоит из нескольких таблиц.

**Person** 
PersonID 
JobID 
LocationID 

**Job** 
JobID 
Name 

**Location** 
LocationID 
Name

Объект Fruit (полностью не связанный с Person) также состоит из нескольких таблиц.

**Fruit** 
FruitID 
ColorID 
ShapeID 

**Color** 
ColorID 
name 

**Shape** 
ShapeID 
Name

Так что в рамках моего проекта у меня есть класс модели для каждой таблицы базы данных. У меня есть контроллер для каждого объекта (FruitController и PersonController)

Так вот где возникает моя путаница:

Должен ли я иметь DbContext для каждого объекта или 1 DbContext для всего проекта?

Теперь предположим, что я создаю миграцию для этого проекта. Создавая миграцию, я предоставляю файл configuration.cs в моей папке Migrations. Откройте этот файл, и есть метод Seed, который принимает DBContext как параметр. Если ваш ответ на предыдущий вопрос состоял в том, чтобы иметь DBC-текст для каждого объекта, то как я могу семенировать каждый объект, поскольку я передаю DBContext в качестве параметра?

Далее идет репозиторий. Должен ли я иметь репозиторий для каждого объекта или 1 для каждой таблицы?

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

источник

2013-11-27 carlg

Вы можете создавать новые теги. Просто так вы знаете –

Не знал. Мне было трудно поверить, что я был первым, кто задал вопрос MVC5, поэтому мне показалось, что кто-то еще создает теги. – carlg

Люди могут быть Фрукты, вы знаете! :) Эмпирическое правило, которое я всегда применял, состоит в том, чтобы иметь 1 контекст для каждой базы данных, к которой вы подключаетесь. Если объекты Person и Fruit хранятся в одной и той же БД, это тот же контекст. – Flater

Я бы порекомендовал использовать один и тот же файл DBContext для обоих объектов, тем более сложно поддерживать базу данных в актуальном состоянии с вашей моделью, если вы используете 2. Это также решает проблему нескольких файлов семян.

Затем вы должны создать другой репозиторий для каждого объекта (так что 1 для фруктов и 1 для лиц). Они оба получат тот же DBContext, который вводится в их конструктор.

Конечно, это не камень, вы должны использовать метод, который имеет для вас наибольший смысл.

источник

2013-11-27 14:09:57

На самом деле, теперь, когда я думаю об этом больше, если вы используете сборку в безопасности, у вас уже есть ApplicationContext, поэтому я могу завершить работу с более чем одним контекстом – carlg

Структурирование приложения ASP.NET MVC (Entity Framework)

ответ

Смежные вопросы