#asp.net-mvc #entity-framework #directory-structure
#asp.net-mvc #entity-framework #структура каталогов
Вопрос:
Я видел несколько проектов с классами Entity Framework DataContext в папке «Модели», но поскольку это на самом деле не модель, это кажется неправильным.
В настоящее время мой DataContext (вместе с классом IDatabaseInitializer) находится в корне моего проекта, но это тоже меня беспокоит.
Есть ли обычная / наилучшая практика для этого, или я должен просто оставить их в корне или папке под названием Data или что-то в этом роде?
Ответ №1:
Возможно, это и есть модель, поскольку она поддерживает состояние вашего приложения. Вот почему люди помещают его туда.
Если ты хороший мальчик и используешь уровень абстракции / репозитория — это должно быть там.
Если ваши контроллеры напрямую взаимодействуют с контекстом EF (плохая идея), то поместите его в папку models — нет необходимости физически скрывать то, что вы не абстрагируете логически.
Комментарии:
1. Проект, над которым я работаю, настолько прост, что абстрагирование контекста EF просто приведет к свойствам / методам, которые переносят контекст один к одному, так что в данном случае это было бы излишеством
2. На самом деле взаимно однозначное сопоставление обычно является признаком плохой архитектуры и анемичной модели предметной области. Но если вы работаете над простым проектом, в котором контроллеры работают непосредственно с ctx, то поместите его в папку models или создайте папку data.
3. Я на самом деле не понимаю, почему это предполагает анемичную модель предметной области, ни как избежать переноса «один к одному», когда весь доступ почти исключительно в форме «из e в db.Entity, где e.Field = value» :/
4. Проверьте эту ссылку, опубликованную в другом ответе: asp.net/entity-framework/tutorials/… Репозиторий — это просто взаимно однозначное сопоставление. Для чего-то настолько простого мне кажется, что это чрезмерная разработка.
5. @Danny — думаю, вы упускаете суть. Еще раз — посмотрите на реализацию
Addметода —ctx.AddObject. Таким образом, репозиторий работает непосредственно с контекстом . Мои репозитории не получают доступа к контексту, они получают доступ к a,IUnitOfWorkкоторый предоставляет только anObjectSet<T>. Я действительно не согласен ни с одной из реализаций в предоставленных вами ссылках. Таким образом, репозиторий не переносит контекст, это делает UoW. Затем репозиторий можно подвергнуть модульному тестированию, передав макет рабочей единицы. Все это объединяется, когда вы начинаете использовать DI.
Ответ №2:
Это не имеет значения. Я поместил его в папку Models, потому что именно туда помещается весь материал базы данных.
Ответ №3:
В других местах, где я работал, решения VS были разделены на 3 проекта:
- Презентация (сайт MVC)
- Сервис (классы бизнес-логики вкл. Сущности POCO)
- Репозиторий (Data access inc. Контексты данных EF)
Комментарии:
1. Это хороший момент, хотя для тривиальных небольших веб-приложений это, вероятно, немного излишне 🙂
2. Для небольших материалов я обычно просто помещаю их в папку
DataилиClassesData.
Ответ №4:
Я скажу, что лучше всего поместить его в model, поскольку это описано в MVC model, и поскольку я работаю над MVC в течение последних 3 месяцев, я очень одобряю это… кроме того, это дает вам большую гибкость при вызове EM-классов…
Ответ №5:
Создайте другой проект с нашим хранилищем данных, добавьте проект в решение и ссылайтесь на него там, где это необходимо. Шаблон репозитория дает преимущества при тестировании и изменении вашего уровня данных в функции по мере необходимости.
Комментарии:
1. В этом примере репозиторий представляет собой просто взаимно однозначное сопоставление. Для чего-то настолько простого мне кажется, что это чрезмерная разработка.
Ответ №6:
Просто мои мысли по этому поводу; для любых классов, связанных с Entity Framework, таких как класс DataContext или базовый класс, мы помещаем их в папку DataFramework. Как и в теории, хотя они расширяют EntityFramework в этом контексте, нет причин, по которым они не могли бы расширить другую платформу базы данных, такую как NHibernate.