ASP.NET MVC — Entity Framework, MySQL и использование Dependency Resolver для выбора репозитория

Решил немного расширить предыдущую статью про ASP.NET MVC и MySQL. В ней речь шла про работу с MySQL в ASP.NET MVC не через практически стандартный ORM Entity Framework (EF), а с помощью прямого доступа к СУБД через ADO.NET. И была приведена реализация этого метода доступа. И хотя метод устаревший и не рекомендуемый к использованию, но иногда полезен: например, в высоконагруженных приложениях или когда разработчик сталкивается с ситуацией, когда ORM не может сгенерировать корректно работающий SQL-запрос. И иногда можно совмещать в приложении оба способа — и через ORM и через ADO.NET. В итоге я подумал, и решил дописать приложение: добавив в него реализацию репозитория для Entity Framework и сделать выбор из них зависимым от параметра приложения с помощью Dependency Resolver.

Весь код можно взять вот по этому адресу, ниже этот код будет частично презентован с небольшими ссылками и пояснениями по отношению к предыдущему проекту. А здесь можно посмотреть на работу приложения.

Изменяем проект

1. Для использования Entity Framework с MySQL мы должны установить библиотеку MySQL.Data.EntityFramework (можно, конечно, и другую, просто эта от Oracle — владельца MySQL).

Она потянет за собой MySQL.Data и собственно EntityFramework. В файл web.config внесены изменения:

<entityFramework>
  <providers>
      <provider invariantName="MySql.Data.MySqlClient" type="MySql.Data.MySqlClient.MySqlProviderServices, MySql.Data.EntityFramework, Version=8.0.19.0, Culture=neutral, PublicKeyToken=c5687fc88969c44d" />
  </providers>
</entityFramework>

С MySQL.Data возникла интересная коллизия — поскольку MySQL.Data.EntityFramework потребовал версии MySQL.Data не ниже 8.0.19, то он обновился… и проект перестал работать. Стала возникать ошибка:

Не удалось загрузить файл или сборку «Ubiety.Dns.Core» либо одну из их зависимостей. Невозможно проверить подпись строгого имени. Возможно, сборка была изменена или построена с отложенной подписью, но не полностью подписана правильным закрытым ключом. (Исключение из HRESULT: 0x80131045)

Видимо в версию MySQL.Data 8.0.19 была добавлена не подписанная сборка Ubiety.Dns.Core. Пришлось в проект ещё и включить этот компонент через Nuget. Ошибка пропала.

2. Кроме этого для реализации внедрения зависимостей добавим в проект Ninject — контейнер внедрения зависимостей (DI).

3. Немного изменим структуру проекта: файлы репозитория вынесем в отдельный каталог Repository и создадим в нём еще подкаталоги ADO.NET (перенесём туда имеющиеся файлы LanguagesRepository.cs и UsersRepository.cs) и EF (тут будут файлы репозитория для Entity Framework).

4. Кроме этого в файл web.config в раздел appConfig добавлен параметр приложения: <add key="ConnectionMethod" value="ADO.NET" />. Приложение будет принимать два значения: «Entity Framework» или «ADO.NET». В файл Base.cs добавил ссылку на этот параметр:

public static string ConnectionMethod
{
    get
    {
        return System.Configuration.ConfigurationManager.AppSettings["ConnectionMethod"];
    }
}

Entity Framework и MySQL – репозитарий

Добавим в каталог RepositoryEF файл DbContext.cs с классом EFDbContext:

public class EFDbContext : DbContext {
    public EFDbContext() : base(Base.ConnectionString)
    { }
    public DbSet<UserClass> Users { get; set; }
    public DbSet<LanguageClass> Languages { get; set; }
}

В нём мы определяем используемую строку подключения к СУБД и наборы данных Users и Languages.

Добавляем файл LanguagesRepository.cs с классом LanguagesRepositoryEF:

public class LanguagesRepositoryEF : ILanguagesRepository
{
    private EFDbContext context = new EFDbContext();
 
    public IList<LanguageClass> List()
    {
        return context.Languages.OrderBy(x => x.LanguageName).ToList();
    }
}

И файл UsersRepository.cs с классом UsersRepositoryEF:

public class UsersRepositoryEF : IUsersRepository
{
    private EFDbContext context = new EFDbContext();
 
    public IList<UserClass> List()
    { 
        return context.Users.ToList();
    }
 
    public IList<UserClass> List(string sortName, SortDirection sortDir, int page, int pageSize, out int count)
    {
        count = context.Users.Count();
        if (sortName != null) return context.Users.OrderByDynamic(sortName, sortDir).Skip((page - 1) * pageSize).Take(pageSize).ToList();
        else return context.Users.OrderBy(o => o.UserID).Skip((page - 1) * pageSize).Take(pageSize).ToList();
    }
 
    public bool AddUser(UserClass user)
    {
        user.Language = context.Languages.Find(user.Language.LanguageID);
        if (user.Language != null && context.Users.Add(user) != null)
        {
            try { context.SaveChanges(); }
            catch (System.Exception ex) {}
        }
        return user.UserID > 0;
    }
 
    public UserClass FetchByID(int userID)
    {
        UserClass user = null;
        try { user = context.Users.Find(userID); }
        catch (System.Exception ex) { }
        return user;
    }
 
    public bool ChangeUser(UserClass user)
    {
        bool result = false;
        user.Language = context.Languages.Find(user.Language.LanguageID);
        if (user.Language != null)
        {
            UserClass olduser = context.Users.Find(user.UserID);
            if (olduser != null)
            {
                olduser.Email = user.Email;
                olduser.Loginname = user.Loginname;
                olduser.Language = user.Language;
                olduser.SupporterTier = user.SupporterTier;
                try { result = context.SaveChanges() > 0; }
                catch (System.Exception ex) { }
            }
        }
        return result;
    }
 
    public bool RemoveUser(UserClass user)
    {
        bool result = false;
        UserClass olduser = context.Users.Find(user.UserID);
        if (olduser != null) context.Users.Remove(olduser);
        try { result = context.SaveChanges() > 0; }
        catch (System.Exception ex) { }
        return result;
    }
}

Видно, что размер файла явно короче подобного для ADO.NET — ORM делает за нас «грязную» работу — создает SQL-запросы самостоятельно.

Однако, я столкнулся с парой моментов, которые прокатывали в реализации ADO.NET, но не работают в EF.

Первый, что пришлось внести изменение в файл UserClass.cs (в каталоге Domain): добавить еще одно поле для нормальной работы связи таблиц Users и Languages:

[HiddenInput(DisplayValue = false)]
public int? LanguageID { get; set; }

И второй — оказалось что поля в MySQL типа Enum не работают через EF. Скорее всего причина этого в том, что перечисление в коде является целочисленным значением, а вот из БД значения через EF читаются как текст (если в запросе из MySQL читать значения поля типа enum MySQL возвращает как раз текстовые значения этого перечисления). И если в версии для ADO.NET я могу это обойти с помощью конструкции CAST(u.SupporterTier AS UNSIGNED) as SupporterTier, то с EF такая метаморфоза оказалась для меня непреодолимой — ни один из пробуемых вариантов не подошёл. Ну и поскольку технология Code First поле типа Enum генерирует в виде поля типа INT, то пришлось в БД поменять тип поля SupporterTier:

CHANGE COLUMN `SupporterTier` `SupporterTier` INT(4) UNSIGNED NOT NULL DEFAULT '1' ;

Выбор репозитория с помощью параметра приложения

Воспользуемся внедрением через конструктор, прямо как написано в учебнике. Во-первых, нам надо создать интерфейсы для нашего общего репозитария: создаем файл LanguagesRepository.cs в каталоге Repository с содержимым:

public interface ILanguagesRepository
{
    IList<LanguageClass> List();
}

И файл UsersRepository.cs с содержимым:

public interface IUsersRepository
{
    IList<UserClass> List();
 
    IList<UserClass> List(string sortName, SortDirection sortDir, int page, int pageSize, out int count);
 
    bool AddUser(UserClass user);
 
    UserClass FetchByID(int userID);
 
    bool ChangeUser(UserClass user);
 
    bool RemoveUser(UserClass user);
}

Ну и наследуем соответствующие классы от этих интерфейсов:

public class LanguagesRepositoryADO : ILanguagesRepository
public class UsersRepositoryADO : IUsersRepository
public class LanguagesRepositoryEF : ILanguagesRepository
public class UsersRepositoryEF : IUsersRepository

Ну и в контроллер UsersController вносим добавления, которые позволят ему работать с этими интерфейсами:

private ILanguagesRepository repLanguages;
private IUsersRepository repUsers;
 
public UsersController(ILanguagesRepository langsParam, IUsersRepository usersParam) 
{ 
    repLanguages = langsParam;
    repUsers = usersParam;
}

И в контроллере изменяем места обращения к объектам этих классов на объекты repLanguages и repUsers, соответственно. Но нам потребуется передавать экземпляры классов репозиториев через конструктор контроллера, что, конечно, неудобно. Чтобы этого избежать, нам нужно сильное колдунство типа Dependency Resolver (DR). И для этого мы будем использовать Ninject:

Регистрируем DR в файле Global.asax.cs в методе Application_Start:

DependencyResolver.SetResolver(new NinjectDependencyResolver());

Создадим файл NinjectDependencyResolver.cs в каталоге Infrastructure с классом NinjectDependencyResolver (унаследовавшего от интерфейса IDependencyResolver):

public class NinjectDependencyResolver : IDependencyResolver 
    { 
        private IKernel kernel; 
        public NinjectDependencyResolver() 
        { 
            kernel = new StandardKernel(); 
            AddBindings(); 
        } 
        public object GetService(Type serviceType) 
        { 
            return kernel.TryGet(serviceType); 
        } 
        public IEnumerable<object> GetServices(Type serviceType) 
        { 
            return kernel.GetAll(serviceType); 
        } 
        private void AddBindings() 
        { 
            if (Domain.Base.ConnectionMethod == "Entity Framework")
            {
                kernel.Bind<ILanguagesRepository>().To<LanguagesRepositoryEF>();
                kernel.Bind<IUsersRepository>().To<UsersRepositoryEF>();
            }
            else
            {
                kernel.Bind<ILanguagesRepository>().To<LanguagesRepositoryADO>();
                kernel.Bind<IUsersRepository>().To<UsersRepositoryADO>();
            }
        }
    }

И получается, что единственное место, в котором определяеся какой метод работы с СУБД используется (напрямую, через ADO.NET или через Entity Framework) это метод AddBindings в классе NinjectDependencyResolver. Настоящая магия, если не знать как это работает.

В методе AddBindings в зависимости от значения параметра приложения «ConnectionMethod» происходит связка интерфейсов ILanguagesRepository и IUsersRepository с конкретными классами реализующими методы интерфейсов. Поскольку при старте приложения мы зарегистрировали DR как объект класса NinjectDependencyResolver, а в классе мы указали привязку интерфейсов репозиториев к конкретному классу, то при запросе фреймворка MVC на создание объекта контроллера UsersController, Ninject при анализе класса обнаружит, что он требует реализацию интерфейсов ILanguagesRepository и IUsersRepository и создаст экземпляры конкретных классов и передаст их в конструктор контроллера (через DR и фрейворк MVC).

Итого

Приложение теперь поддерживает и метод доступа к СУБД через ORM Entity Framework. При этом метод доступа через ADO.NET никуда не делся и выбирается при запуске приложения по параметру, для чего было использован метод внедрения зависимости через конструктор контроллера с помощью библиотеки Ninject.

P.S. И напоследок: посмотреть, как работает данный проект можно по этому адресу. А вот тут можно скачать весь проект. Ну и до кучи — ссылка на мой блог.

Автор: Duke

Источник