{"id":280,"date":"2016-02-17T00:46:33","date_gmt":"2016-02-16T22:46:33","guid":{"rendered":"http:\/\/localhost\/wordpress\/?page_id=280"},"modified":"2016-09-26T00:56:01","modified_gmt":"2016-09-25T22:56:01","slug":"entity-framework","status":"publish","type":"page","link":"https:\/\/blog.ghbss.de\/?page_id=280","title":{"rendered":"Entity-Framework"},"content":{"rendered":"

Um die Daten zu persistieren und als ORM-Framework haben wir uns f\u00fcr Entity-Framework (Version 6) entschieden.<\/p>\n

Code-First<\/h2>\n

Code-First bietet die gr\u00f6\u00dften Freiheit bei der Erstellung der DALs daher auch unsere erster Wahl.<\/p>\n

Models Erstellen<\/h2>\n
\"CompositePattern\"<\/a>

Composite Pattern<\/p><\/div>\n

F\u00fcr die Erstellung der Model-Klassen nehmen wir die Datenstruktur der „Composite-Pattern“ her.<\/p>\n

Hier wird der gemeinsame Basis-Klasse als Schnittstelle (Interface) verwendet um die Daten bereitzustellen bzw. entgegen zunehmen.<\/p>\n

Bei der Einsatz der „Code-First“-Methode habe ich festgestellt, dass EF beim Speichern der Objekte darauf achtet , ob eine extra Tabelle f\u00fcr „Component“-Models erzeugt werden muss oder nicht.<\/p>\n

Es h\u00e4ngt stark von den Datenbasis ab, ob jetzt weitere Klassen von „Composite“\/“Leaf“-Abgeleitet werden oder jeweils eine neue Klasse erzeugt werden muss.<\/p>\n

Datenbank-Context<\/h2>\n

Wenn der DAL(Data Access Layer) in ein externes Bibliothek erzeugt und definiert wird, Connection-String muss in alle config-files gespeichert werden.<\/em><\/p>\n

 <\/p>\n

Connection-String<\/h3>\n

Wird in Web- oder App-.Config Datei definiert und sieht wie folgt aus:
<connectionStrings>
<add name=\"SchoolContext\" connectionString=\"Data Source=(localdb)MSSQLLocalDB;Initial Catalog=PROJECTCATALOG<\/b>;Integrated Security=SSPI;\" providerName=\"System.Data.SqlClient\" \/>
<\/connectionStrings>
<\/code>
Hier wird auf dem lokalen sql-server ((localdb)MSSQLLocalDB<\/strong><\/em>) ein Catalog\/Datenbank(PROJECTCATALOG<\/b>) benutzt.<\/p>\n

Datenbank Initialisieren<\/h3>\n

Hier geht\u2019s darum den Datenbank jedes mal l\u00f6schen und neu erstellen , wenn sich die Definition der Models sich \u00e4ndert.<\/p>\n

Hierf\u00fcr erstellt man erst eine Klasse die von „System.Data.Entity.DropCreateDatabaseIfModelChanges“.
In diese Klasse \u00fcberschreiben wir dann die Methode:“Seed“<\/p>\n

public class ProjektDbContextInitializer: System.Data.Entity.DropCreateDatabaseIfModelChanges {
protected override void Seed(ProjektDbContext context) {
\/\/ Model-Objekte erzeugen und dem Context hinzuf\u00fcgen
\/\/ context.SaveChanges() aufrufen um die Daten zu speichern
}
}
<\/code><\/p>\n

Beziehungen<\/h2>\n

One-to-Many<\/h3>\n

Hierf\u00fcr man definiert eine am besten virtuelle Collection in der Klasse:

class Composite: Component {
public virtual ICollection children {get; set;}
public Composite() {
children = new
}
}
<\/code><\/p>\n

One-to-One<\/h3>\n

Many-to-Many<\/p>\n

 <\/p>\n

Links(Intern):<\/h2>\n