Разработка решения для базы данных ASP.NET MVC и Entity Framework - PullRequest
Новая
       43

Разработка решения для базы данных ASP.NET MVC и Entity Framework

0 голосов
/ 17 марта 2019

Я унаследовал решение ASP.NET (4.6.1) MVC, которое использует Entity Framework (сначала базу данных) в качестве доступа к данным.Все вызовы dbcontext и вся бизнес-логика находятся в методах контроллера.Здесь нет моделей доменов .... только просмотр моделей и созданных моделей объектов из EF.

Итак, структура решения в основном:

  • Web (веб-проект MVC) → DAL (EF6 ... class lib proj)
  • DAL содержит
    • .edmx
    • dbContext - автоматически сгенерированный
    • Модели объектов - автоматически сгенерированный
    • Частичные классы для моделей объектов
    • Частичный dbcontext (содержит некоторыепользовательская логика)
  • MVC
    • Контроллер
    • Приватный dbcontext на уровне класса
    • Некоторые простые или сложные вызовы CRUD dbcontext в каждом методе
    • Модели
    • Только просматривать модели (некоторые с вызовами dbcontext ... oy)
  • Представления
    • В некоторых представлениях виртуальные машины используются каких модель, в то время как другие используют модели сущностей EF

По крайней мере, я хочу изолировать мой DAL от уровня представления и очистить мои контроллеры.Я не пытаюсь создать идеальное приложение ... но я хочу делать постепенные улучшения.Итак, моя цель в этом раунде - создать логическую структуру.

Итак, я добавляю другой проект между Web и DAL (называемый Service или чем-то еще) и перемещаю в него все вызовы / логику dbcontext.слой.Я добавляю еще один проект (называемый Core) для хранения нескольких DTO, пользовательских исключений и других полезностей.

Итак, это мое текущее решение:

  • Web (веб-проект MVC с Autofac)

    • Некоторые классы диспетчера служб (внедряются в контроллеры)
    • Здесь я получаю свои DTO и преобразовываю их в модели представлений или преобразовываю модели представлений в DTO для отправки на уровень обслуживания

  • Core (непутать с .NET Core)

    • Ссылка на все
    • Модели сущностей (перенесено из DAL)
    • Частичные классы для моделей сущностей (перенесено из DAL)
    • DTO, исключения и т. Д. ...

  • Сервис

    • Ссылка через Интернет
    • Некоторые сервисыклассы (внедренные в менеджеры Web-сервисов), которые будут содержать все сложные вызовы dbcontext CRUD, ранее использовавшиеся в методах контроллера (например: var result = dbcontext.SomeTable where some id = n...blah blah)
    • Я также внедряю dbcontext DAL в эти классы (для чего затем требуетсяссылка на Entity Framework)

  • DAL

    • Ссылкаd by Service
    • .edmx
    • Dbcontext
    • Частичный dbcontext (содержит некоторую пользовательскую логику)

Итак, ясохраняю автоматически сгенерированный dbcontext в DAL, перемещая сгенерированные объекты сущности в Core, чтобы Service мог их видеть.

Мои вопросы:

  1. Имеет ли смысл перенести все вызовы / логику dbcontext из контроллеров в Сервис?Часть логики проста, но есть несколько методов контроллера, которые также содержат сложную бизнес-логику.Я просто не уверен, куда поместить эту логику / вызовы в dbcontext.

  2. Общий дизайн решения кажется нормальным или я усложняю его?Это приложение среднего размера, но у него есть потенциал для роста, и я хочу настроить себя на дальнейшее развитие.

Спасибо за чтение ... любой вклад приветствуется!

...