Разширения на Entity Framework 6, за които може би не знаете
- Първа база данни без EDMX
- Работа с отделени графики
- SQL модификация. Добавяне на съвети за таблица
- Кеширане на данни извън живота на DbContext
- Опитайте отново при грешки от SQL Server
- Заместване на DbContext, изолиране от реалната база данни
- Бързо вмъкване
Първа база данни без EDMX
Не искам да започвам нов кръг от аргументи „Първо код срещу база данни Първо“. Предпочитам просто да ви кажа как да улесните живота си, ако предпочитате Database First. Много разработчици, използващи този подход, намират за неудобно да работят с обемен .edmx файл. Този файл може да направи разработката на екип ада, което прави много трудно обединяването на паралелни промени поради постоянното "смесване" на вътрешната му структура. Сред другите недостатъци, за модели с няколкостотин обекта (обичайният такъв наследен монолит), може да изпитате голям спад в скоростта на всяко действие, когато работите със стандартен EDMX дизайнер.
Решението изглежда очевидно - необходимо е да се изостави EDMX в полза на алтернативни средства за генериране на POCO и съхраняване на метаданни. Задачата не е трудна и EF я има от кутията - това е елементът "Generate Code First From Database", наличен във Visual Studio (VS2015 със сигурност). Но на практика е много неудобно да се прехвърлят промени в базата данни върху получения модел чрез този инструмент. Освен това, тези, които работят с EF от дълго време, може би си спомнят разширението Entity Framework Power Tools, което решава подобни проблеми - но, уви, проектът вече не се разработва (не можете да го инсталирате на VS2015 без хак) и някои от разработчиците на този инструмент вече работят директно в екипа на EF.
Изглежда, че всичко е лошо - и тук открихме EntityFramework Reverse POCO Generator. Това е T4 шаблон за генериране на POCOвъз основа на съществуваща база данни с много персонализиране и отворен код. Поддържат се всички основни характеристики на EDMX и има редица допълнителни екстри: генериране на FakeDbContext/FakeDbSet за тестване на модули, покриване на модели с атрибути (напр. DataContract/DataMember) и др. Благодарение на T4 има пълен контрол върху генерирането на код. Накратко: работи стабилно, екипът го харесва, лесно е да мигрирате съществуващи проекти.
Работа с отделени графики
Прикачването на нов или един обект, получен преди това в друг контекст, към DbContext обикновено е лесно. Проблемите започват в случай на графики, т.е. обекти с релации - EF "извън кутията" не проследява промените в съдържанието на навигационните свойства на новоприкачения обект към контекста. За да се проследят промените, за всеки обект на обект по време на живота на контекста трябва да има съответен запис - обект със служебна информация, включително състоянието на обекта (Добавен, Променен, Изтрит и т.н.). Попълнете записите, за да прикачите графиката - възможни са поне 2 начина:
- Съхранявайте състоянието в самите обекти, като проследявате промените сами. Така нашата несвързана графика ще съдържа цялата необходима информация за присъединяване.
- Не правете нищо предварително и когато добавяте графика към нов контекст, изтеглете оригиналната графика от базата данни и задайте състоянията на въвеждане въз основа на сравнение на две графики.
Примерза решение #1 може да бъде намерен, например, в скорошен курс на Pluralsight от Джули Лерман, известен експерт по EF. За независимото му генерично изпълнение са необходими голям брой жестове. Всички обекти трябва да имплементират интерфейса IStateObject:
По един или друг начин е необходимо да се гарантира уместносттаЗадайте стойности, така че след ръчно прикачване на всеки обект в графиката към контекста:
прегледайте всички записи, като редактирате състоянието им:
В този случай нямаме нужда от допълнителни извиквания на база данни, но решението е обемисто, крехко и потенциално неработещо за релации много към много. Моделите също бяха осеяни (между другото, изискването за внедряване на интерфейса може да бъде разрешено чрез модифициране на шаблоните T4 от предишния раздел на статията).
Помислете зарешение #2. Ще бъда кратък:
SQL модификация. Добавяне на съвети за таблица
Генерирането на привидно прост оператор SELECT ... FROM Table WITH (UPDLOCK) не се поддържа от EF. Но има прехващачи, които ви позволяват да модифицирате генерирания SQL по всеки подходящ начин, например с помощта на регулярни изрази. Нека добавим UPDLOCK към всеки генериран SELECT в рамките на живота на контекста (разбира се, детайлността не е непременно контекст, всичко зависи от вашата реализация):
За да направим това, ние декларираме метода With вътре в контекста и регистрираме прехващача: