Hallo Leute,
ich arbeite im Moment an einem Testprojekt für eine 3-Layer Architektur. Es handelt sich dabei zunächst um eine kleine Adressverwaltung.
Jede Schicht greift auf die darunterliegende über ein Interface zu. Die Business-Schicht leitet die Objekte aus dem Data-Layer weiter. Hier (in der Business-Schicht) sollten später Validierung und Filterung stattfinden. Durch das Save im Datalayer werden alle Änderungen in die Datenbank übernommen.
 C#-Code: |
public interface IBusinessRepositoryAdressen
{
IQueryable<IAdressen> Get();
Boolean Save();
IAdressen Create();
}
|
| C#-Code: |
public interface IDataRepositoryAdressen
{
IQueryable<IAdressen> Get();
void Save();
IAdressen Create();
void Add(IAdressen adr);
void Delete(IAdressen adr);
}
|
| C#-Code: |
public interface IAdressen
{
int ID { get; set; }
string Name { get; set; }
string Vorname { get; set; }
string Strasse { get; set; }
string PLZ { get; set; }
string Ort { get; set; }
}
|
Im Data-Layer werden die Adressobjekte aus der Datenbank mit Hilfe des Entity-Frameworks erzeugt:
| C#-Code: |
private static IQueryable<IAdressen> Get(AdressenEntities ae)
{
IQueryable<IAdressen> result = from adresse in ae.Adressen
select adresse;
return (IQueryable<IAdressen>)result;
}
|
Die durch das EF erzeugten Objekte werden also in allen Schichten verwendet (durch das Inteface haben die oberen Schichten allerdings keinen Zugriff auf die EF-Logik.
Ich bin mir allerdings nicht sicher ob eine so enge Bindung das das EF bei einer größeren Anwendung zu Problemen führen könnte. Viele Quellen raten davon ab die Datenbankentitäten aus dem O/R-Mapper in den oberen Schichten zu verwenden.
Nur was stellt die Alternative dar? Durch mein derzeitiges Konzept kann (dank IQueryable) die Filterung der Daten in der Business-Schicht erfolgen. Da es sich um eine Neuentwicklung handelt entsprechen meine Business-Objekte 1:1 den Datenbanken. Entsprechende Unterschiede kann ich immer noch durch eine partielle Klasse ausgleichen.
Nach meinem jetzigen Verständnis müsste ich ein Business-Adressen-Objekt erzeugen, welches fast 1:1 der vom EF erzeugten Klasse entspricht. Dann müsste ich (in meinem Fall in der Business-Schicht) nach dem Filtern, aus den Datenbankentitäten die Business-Adressen-Objekte erzeugen (Mappen).
Das erscheint mir allerdings im Anbetracht des geringen Nutzen sehr viel Arbeit. Damit meine ich nicht nur aus Code-Sicht sondern auch den Performance-Verlust der durch das Mappen entsteht.
Wie sind euere Erfahrungen? Kapselt/Mappt ihr eure Datenbankentitäten?
