3. Mit Entity Framework habe ich gar keine Kontrolle über meine Tabellen
Das ist ein hartnäckiges Vorurteil gegenüber Entity Framework, welches aber nicht ganz wahr ist. Wenn eine Zwischentabelle (für eine n-zu-m Beziehung) in Entity Framework erstellt wird, wird die Zwischentabelle mit dem Namen der verbundenen Entitäten erstellt.
public class Employee
{
public string Firstname { get; set; }
public string Lastname { get; set; }
public virtual ICollection<Skill> Skills { get; set; }
}
public class Skill
{
public string Name { get; set; }
public int Level { get; set; }
public virtual ICollection<Employee> Employees { get; set; }
}
Daraus kann nun eine EmployeeSkills oder eine SkillEmployees Tabelle entstehen. Die Erstellung dieser Zwischentabelle kann mit der Fluent-API gesteuert werden.
protected override void OnModelCreating(DbModelBuilder modelBuilder)
{
modelBuilder.Entity<Employee>()
.HasMany<Skill>(e => e.Skills)
.WithMany(s => s.Employees)
.Map(es =>
{
es.MapLeftKey(“EmployeeRefId”);
es.MapRightKey(“SkillRefId”);
es.ToTable(“EmployeeSkillList”);
});
}
Die Methoden HasMany() und WithMany() werden zur Konfiguration von n-zu-m Beziehungen verwendet. Danach wird mit der Map() Methode die Tabelle mit dem gewünschten Namen definiert.
Wichtig: Die Entität, aus welcher die HasMany() Methode aufgerufen wird (in unserem Beispiel die Employee Entität), wird mit MapLeftKey() in die „linke Spalte“ geschrieben.
4. SQL + Entity Framework = <3
Eine Kombination aus SQL und Entity Framework ist immer möglich. Die Performance bei komplexen Abfragen mit vielen ungewollten JOINS kann Entity Framework schnell in die Knie zwingen. Eine Kombination aus Entity Framework und einer SQL View kann die Performance enorm anheben. Im nächsten Beispiel haben wir eine sehr simple View, die uns die Namen der Mitarbeiter, deren Skills und deren Skillstufe anzeigt:
CREATE VIEW SkillOverview AS
SELECT E.Firstname as Firstname, E.Lastname as Name, S.Level as Level, S.Name as Skill FROM Employees E
JOIN EmployeeSkillList ESL ON ESL.EmployeeRefId = E.Id
JOIN Skills S ON S.Id = ESL.SkillRefId
Als nächstes erstellen wir ein Datenmodell:
public class SkillOverviewModel
{
public string Firstname { get; set; }
public string Name { get; set; }
public int Level { get; set; }
public string Skill { get; set; }
}
Nun erstellen wir eine Methode, die uns das Datenmodell anhand der View befüllt:
public ICollection<SkillOverviewModel> GetSkillOverview()
{
string query = “SELECT * FROM [dbo].[SkillOverview]”;
List<SkillOverviewModel> result = this.context.Database.SqlQuery<SkillOverviewModel>
(query).ToList();
return result;
}
Mit demselben Prinzip können auch SQL-Functions und Stored Procedures angesprochen werden. Die Parameter werden als SqlParameter Array übergeben. Wenn wir also nur die Mitarbeiter mit einem bestimmten Skill-Level sehen wollen entwickeln wir eine neue Methode:
public ICollection<SkillOverviewModel> GetSkillOverview(int skillLevel)
{
string query = “SELECT * FROM [dbo].[SkillOverview] WHERE [Level] = @skillLevel”;
List<object> parameters = new List<object>();
SqlParameter skillLevelParameter = new SqlParameter(“@skillLevel”, skillLevel);
parameters.Add(skillLevelParameter);
List<SkillOverviewModel> result = this.context.Database.SqlQuery<SkillOverviewModel>
(query, parameters.ToArray()).ToList();
return result;
}
5. Darf es noch ein wenig mehr sein?
Durch den Code First-Ansatz spiegeln unsere Entitäts-Objekte eine ganze Zeile einer Tabelle ab. In einigen Anwendungen können Entitäten viele Eigenschaften haben, die gar nicht immer benötigt werden.
public class Employee
{
public int Id { get; set; }
public string Firstname { get; set; }
public string Lastname { get; set; }
public virtual ICollection<Skill> Skills { get; set; }
}
class Program
{
static void Main(string[] args)
{
AppContext context = new AppContext();
List<Employee> employees = context.Employee.ToList();
Console.ReadKey();
}
}
Diese Abfrage liefert uns nun alle Einträge in der Employee Tabelle. Dadurch wird Id, Firstname und Lastname von jeder Entität geladen. Aber was ist mit den Skills eines Mitarbeiters? Lazy Loading ist standardmäßig aktiviert bei Entity Framework. Dadurch werden die Skills erst dann geladen, wenn diese gebraucht werden.
static void Main(string[] args)
{
AppContext context = new AppContext();
List<Employee> employees = context.Employee.ToList();
foreach(Employee employee in employees)
{
Console.WriteLine($”{employee.Firstname} {employee.Lastname}”);
foreach(Skill employeeSkill in employee.Skills)
{
Console.WriteLine($”{employeeSkill.Name}: {employeeSkill.Level}”);
}
}
Console.ReadKey();
}
Alle Employees sind bereits geladen, aber deren Skills leider nicht. Dadurch wird in der inneren foreach-Anweisung jedes Mal ein Request zur Datenbank geschickt und lädt den Skill nach. Besser wäre es, wenn die Skills direkt mit den Employees geladen werden. Mit der Include() Methode lässt sich das einfach realisieren:
List<Employee> employees = context.Employee.Include(e => e.Skills).ToList();
6. Das habe ich doch gar nicht gebraucht!
Wie wir sehen, verwenden wir nur FirstName und LastName von Employee sowie Name und Level von Skill. Mitgeladen wird aber auch jeweils die Id. Unser Beispiel ist etwas “klein”, aber stellen Sie sich vor, Sie haben zwei Entitäten mit verschiedenen Datentypen wie Datum, Integer, Float und davon auch noch viele. Diese werden nicht benötigt, aber auch geladen. In SQL würden wir auch nicht
SELECT * FROM [TABLE]
ausführen, um dann nur die Daten aus der Menge zu nehmen, die wir brauchen. Wieso sollten wir das dann bei Entity Framework tun?
Unser Ergebnis von der Query kommt wieder in ein Model:
public class FullNameModel
{
public string FullName { get; }
public FullNameModel(Employee employee)
{
this.FullName = $”{employee.Firstname} {employee.Lastname}”;
}
}
public ICollection<FullNameModel> GetAllFullNames()
{
List<FullNameModel> result = this.context.Employee
.Select(x => new FullNameModel
{
FullName = $”{x.Firstname} {x.Lastname}”
}).ToList();
return result; }
Übersetzt lautet dieser Code: SELECT Firstname, Lastname FROM [Employees] also genau das, was wir brauchen. Ein Entity Framework Select-Statement mit einem angepasstem Data Transfer Object(DTO) kann genauso schnell sein wie ein direktes SQL Statement.
Wichtig: Im Select-Statement kann nur ein parameterloser Konstruktor verwendet werden.
Fazit
Entity Framework oder SQL? Wieso nicht beides? Entity Framework kann die Arbeit erleichtern, aber nicht alles ist standardmäßig genau so eingestellt, wie der Entwickler es gerade braucht. Durch eine gute Kombination aus Entity Framework und SQL können Schwächen kompensiert und Entwicklungszeit verkürzt werden. Dank Codefirst wird die Datenbankgenerierung in der Codeverwaltung gespeichert und ein Wechsel der Datenbankengine ist einfacher zu realisieren. Der Einsatz von Entity Framework ersetzt nicht das Grundwissen von relationaler Datenmodellierung, sondern sollte diese ergänzen.
