Verwendung des EF Persistence Framwork

In einem vorherigen Artikel habe ich mein EF Persistence Framework (EFPF) vorgestellt. Nun möchte ich etwas zu dessen Verwendung schreiben.
Wie schon erwähnt, kann EFPF sowohl den Model/Database-First (Forward- oder Reverseengineering) als auch den Code-First-Ansatz unterstützen. In der Assembly gibt es zwei Namespaces für die entsprechenden Ansätze. Der Code-First-Ansatz befindet sich in CSP.EFPF.CodeOnly, in CSP.EFPF.Database sind die Klassen für Model/Database-First.

Hinweis zum Model/Database-First
Möchte man diesen Ansatz verwenden, muss man den ADO.NET POCO Code Generator als Codegenerierungselement verwenden. Mit dem Standard bekommt man einen Fehler beim Auflösen des Modelltyps. Da die POCO-Klassen von keiner Basisklasse ableiten (POCO eben), gibt es hier keine Interferenzen.

Einbinden in Anwendungen
Um EFPF zu verwenden muss man natürlich den Verweis zur Assembly (.Net 4.0) hinzufügen. Nun benötigt man Schnittstellen, welche die Funktionen der gewünschten Repositories beschreiben. Diese werden für die Entkopplung der Teile benötigt und werden von DI-Container (bei mir Ninject) verwendet. Diese Schnittstellen müssen von der Schnittstelle IRespsitory erben, welche im Namespace CSP.EFPF.Common liegt.
[csharp]
//Beispiel einer eigenen Repository-Schnittstelle
public interface IPersonRepository : IRepository
{
IEnumerable GetPersons();
}
[/csharp]

Nun erstellt man das eigentliche Repository als Klasse und erbt von BaseRepository. Hierbei ist zu beachten, dass man den richtigen Namespace für BaseRepository verwendet; CodeOnly – CSP.EFPF.CodeOnly, Model(EDMX) – CSP-EFPF.Database. Auch die erstellte Schnittstelle muss implementiert werden.
[csharp]
public class PersonRepository : BaseRepository, IPersonRepository
{
[Inject]
public PersonRepository(IUnitOfWork unitOfWork)
: base(unitOfWork)
{
}

public IEnumerable GetPersons()
{
return GetAll();
}
}
[/csharp]
Wie zu erkennen ist, wird im Konstruktor eine IUnitOfWork übergeben. Dies wird bei entsprechender Konfiguration mittels Dependency Injection aufgelöst, siehe Attribut [Inject]. Alle weiteren Initialisierungarbeiten werden vom Konstruktor der Basisklasse übernommen. Daher ist der Aufruf dieses Konstruktors notwendig.
Die Basisklasse bringt Methoden für alle CRUD-Arbeiten mit. Somit kann man eine Ebene weiter oben mit seinen Programmiertätigkeiten beginnen.

Möchte man nun ein Repository verwenden, sollte man nur gegen das entsprechende Interface arbeiten. Somit lässt sich auch gleich die Erzeugung der Instanzen an den IoC delegieren.
[csharp]
public class HomeController : Controller
{
private IPersonRepository repos;
private IRatingRepository ratings;

//Repositories werden injiziert (Ninject – DI)
public HomeController(IPersonRepository repos, IRatingRepository ratingRepos)
{
this.repos = repos;
this.ratings = ratingRepos;
}

private void Init()
{
var liste = repos.GetPersons();

ViewBag.Liste = liste;
ViewBag.Ratings = ratings.GetAll();
}

public ActionResult Index()
{
Init();
return View(repos.GetPersons().Last());
}
}
[/csharp]

Den IoC kann man nun nach belieben konfigurieren. Ich empfehle die Instanzlebenszeit bei Webanwendungen auf Request zu setzen. Somit hat man bei jedem Aufruf einen neuen EF-Context und somit auch immer aktuelle Werte plus den Vorteil des Trackings der Objekte während der Verarbeitung.

Ein Gedanke zu “Verwendung des EF Persistence Framwork

Kommentar verfassen

Trage deine Daten unten ein oder klicke ein Icon um dich einzuloggen:

WordPress.com-Logo

Du kommentierst mit Deinem WordPress.com-Konto. Abmelden /  Ändern )

Google Foto

Du kommentierst mit Deinem Google-Konto. Abmelden /  Ändern )

Twitter-Bild

Du kommentierst mit Deinem Twitter-Konto. Abmelden /  Ändern )

Facebook-Foto

Du kommentierst mit Deinem Facebook-Konto. Abmelden /  Ändern )

Verbinde mit %s