Контекст нескольких баз данных против UnitofWork с шаблоном репозитория при использовании внедрения зависимостей - PullRequest
Новая
       82

Контекст нескольких баз данных против UnitofWork с шаблоном репозитория при использовании внедрения зависимостей

0 голосов
/ 30 января 2019

Я работаю над приложением с несколькими модулями.Я создал таблицы для разных модулей в разных схемах в одной базе данных и во всех пользовательских таблицах в схеме по умолчанию.Я чувствую себя более смущенным после прочтения больше о dbcontext, единице работы и шаблоне репозитория.Я начал создавать один dbcontext и понял, что вошедшему в систему пользователю нужно немного таблиц, но, вызвав конструктор, он перенесет все в память.Позже я подумал о создании нескольких dbcontexts, но я должен включить пользовательские таблицы во все dbcontexts.

В качестве третьего варианта я начинаю работать с unitofwork и шаблоном репозитория.Во многих статьях говорилось, что это просто еще одна абстракция поверх EF с DBContext и DBSet.Я все еще продолжал работать и понял, что у меня будут сотни репозиториев, и как только я добавлю их все в unitofwork и вызову конструктор, снова все будет загружено в память.Я совершенно не понимаю, какой подход лучше всего подходит для моих нужд.Каждому контроллеру нужны только определенные репозитории таблиц и репозитории пользовательских таблиц для операций CRUD, но, выполнив вышеперечисленные шаги, это вызовет проблемы с производительностью?

Мой unitofwork такой, как показано нижеконтроллер 

using DemoApp.Core;
using DemoApp.Core.Domain;
using DemoApp.Persistence;
using System;
using System.Linq;
using System.Web.Mvc;

namespace DemoApp.Controllers
{
    public class HomeController : Controller
    {
        private readonly IUnitOfWork _unitOfWork;
        public HomeController(IUnitOfWork unitOfWork)
        {
            _unitOfWork = unitOfWork;
        }
        public ActionResult Index()
        {
            var result = _unitOfWork.Ones.GetAll();
            return View(result);
        }
    }
}

1 Ответ

0 голосов
/ 30 января 2019

Наличие одного большого контекста не будет загружать сущности в память при построении, но разрешит сопоставления сущностей, которые могут занять несколько секунд в очень больших контекстах для первой загрузки.Ограниченные контексты подходят для очень больших систем, в которых вы можете отделить связанные сущности или отделить «тяжелые» или чувствительные ко времени сущности от основного контекста использования.

Я использую шаблон с ограниченными контекстами, в котором используется атрибут, типизированный дляРассматриваемый контекст, чтобы отметить, какие конфигурации типов сущностей применимы к какому контексту.Это позволяет использовать более мелкие, подходящие только для чтения определения сущностей.Я бы действительно рекомендовал это только для очень больших наборов сущностей.Использование отложенного выполнения и выражений .Select () для извлечения только тех данных, которые необходимы, когда это необходимо, использование нескольких объединенных объявлений сущностей обычно не требуется.

Аргумент для использования шаблонов Unit of Work & Repository в первую очередьвокруг включения модульного тестирования.Я не рекомендую использовать универсальные репозитории (репозиторий для каждой сущности), а использовать шаблон репозитория так же, как вы используете шаблон контроллера.Каждый репозиторий обслуживает область приложения с методами для извлечения, создания и удаления объектов, относящихся к этой области.Привязка репозитория к одному объекту приводит к большому количеству стандартного кода или общих операций, которые не относятся ко всем объектам одинаково.Это делает ваш код менее гибким и в конечном итоге труднее для чтения.В большинстве случаев вы должны использовать отношения, отображаемые между объектами, поэтому один репозиторий может управлять извлечением и воздействием, например, на все соответствующие объекты для определенного экрана, а не переключаться между множеством различных репозиториев, чтобы попытаться загрузить соответствующие данные.Я использую шаблон DbContextScope UoW от Mehdime, поскольку он облегчает как чтение / запись, так и области только для чтения в репозиториях / помощниках и устраняет необходимость вставлять оболочку dbcontext / UoW в репозитории.Это позволяет иметь несколько областей действия UoW в запросе по сравнению с областью видимости экземпляра DbContext / UoW для запроса или вручную возиться с областями действия на весь срок действия, если ваш контейнер поддерживает это.В любом случае стоит посмотреть как вариант.Реализация Mehdime для EF 6.x, в то время как для EF Core доступны вилки.

...