Hallo,
ich habe mehrere Assemblies, jeweils eine für jede Schicht:
Projekt.Data -> Datenbank-Schicht
Projekt.Application -> Business-Schicht
Projekt.Definitions -> Business-Objekte
Nun habe ich verschiedene Objekte bei denen bestimmte Properties zwar gelesen, aber nicht gesetzt werden dürfen. Allerdings muß ich in der Datenbank-Schicht, diese natürlich setzen.
Ich habe es nun mit dem Schlüsselwort internal ausprobiert. Dieses beschränkt den Zugriff allerdings auf Assembly Ebene. Da meine Datenbank-Schicht sich allerdings in einem anderen Assembly befindet, kann ich von dort aus auch nicht zugreifen.
Hat Jemand eine Lösung für dieses Problem?
moin
du Könntest die jeweiligen Properties als privat deklarieren und per reflection drauf zugreifen
mfg
Hallo Naffel9,
die Datenbank-Schicht sollte ohnehin nicht auf die Business-Schicht zugreifen.
herbivore
Hallo,
meine Business-Schicht greift eigentlich auch gar nicht auf die Datenbank-Schicht zu.
Die Datenbank-Schicht gibt es Business-Objekt zurück, welches dann in der Business-Schicht verarbeitet oder weitergegeben werden kann.
Das Problem besteht aber trotzdem.
Original von herbivore
die Datenbank-Schicht sollte ohnehin nicht auf die Business-Schicht zugreifen.
Original von Naffel9
meine Business-Schicht greift eigentlich auch gar nicht auf die Datenbank-Schicht zu.
Die Business-Schicht darf (und wird) auf die Datenbank(zugriffs)schicht zugreifen. Andersherum ist ein Problem, wie herbivore schon sagt.
Was sind denn die "verschiedenen Objekte", deren Eigenschaften du setzen willst und was ist ihre Funktion?
Viele Grüße,
Andre
Hallo,
Ich habe z.B. ein Objekt User. Dieses Objekt hat ein Property Username, welches nicht geändert werden darf.
Original von Naffel9
meine Business-Schicht greift eigentlich auch gar nicht auf die Datenbank-Schicht zu.Die Datenbank-Schicht gibt es Business-Objekt zurück, welches dann in der Business-Schicht verarbeitet oder weitergegeben werden kann.
Ich glaube Du solltest mal überlegen ob das der richtige Weg ist.
Meiner Meinung nach darf der DataAccessLayer keine Kenntnis vom BusinessLayer haben, sondern einfach nur Daten aus der Persistenz übertragen.
Außerdem gibts dann Crossreferenzen.
DAL refenziert auf BAL
BAL Referenzierzt auf DAL.
Wenn Du in deiner Businessschicht Daten aus der DAL holst könntest Du auch
internal so verwenden wie es vorgesehen ist, um dort halt die Werte aus der Db
dem Feld zuzuweisen.
Ich weiss ja nicht wie weit fortgeschritten dein Projekt ist, aber überdenke mal die Architektur. Wenn Du es nicht änderen willst oder kannst dann musst Du mit den Einschränkungen leben.
Jörg
Hallo Jörg,
Original von joerg.uth
Ich glaube Du solltest mal überlegen ob das der richtige Weg ist.
Meiner Meinung nach darf der DataAccessLayer keine Kenntnis vom BusinessLayer haben, sondern einfach nur Daten aus der Persistenz übertragen.
Wie übergibt die DAL denn in deinem Fall die Daten an die BAL? Und wie übergibt die BAL, die Daten an die DAL?
Class User
{
private string username;
public string UserName
{
get{return this.username;}
}
public User(Guid userId)
{
DataRow row = DAL.GetUserById(userId);
this.username = (string)row["UserName"];
}
}
Jörg
Ziel von mir war es, durch alle Schichten hindurch mit einem Objekt zu arbeiten, daher auch die Definitions-Schicht.
Ich denke die Lösung ist auch ziemlich gut (so weit ich das beurteilen kann), bis auf die Tatsache, daß ich manche Properties nicht einschränken kann.
Mein DAL hat übrigens auch keine Kenntnis vom BAL. Die einzige Referenz besteht in Form der gemeinsamen Objekte.
Die Architektur ist an PWA von Patrick Lorenz angelehnt.
Wenn deine Definitions nur zur Vorratsspeicherung dienen dann kann man ja auch damit arbeiten. Früher, hi hi, gabs ein Beispiel nannte sich Duvamisch oder ähnlich
dort ging es um Enterpriselösungen.
Dort wurden keine sog. Definitions sondern Commons erstellt, was aber im Grunde ähnlich ist. Nur gabs beim 1.0 bzw. 1.1 keine Generics also
wurde nicht <LIST> genommen sondern alles von DataTable abgeleitet.
Obs jetzt ne DataRow oder eine Common.User ist, macht eigentlich keinen grossen Unterschied das eine ist typisiert das andere nicht.
Eines haben Sie aber gemeinsam; Den Datentransport nichts anderes.
Man muss nur aufpassen das man bei gleichem Namen auch das richtige Object meint.
BAL.User != Common.User
BAL.User u = new BAL.User(foo);
Label.Text = u.UserName;
In der Klasse BAL.User
public class User
{
private string username;
public string UserName
{
get{return this.username;}
}
public User(Guid userId)
{
Common.User u = BAL.GetUserById(userId);
this.username = u.username;
}
}
In der DAL
public Common.User GetUserById(Guid userid)
{
Common.User u = new Common.User();
// Blablablub Datenbank
u.UserName = dr.GetString(0);
return u;
}
Jörg
Stimmt aber das eine ist dein BusinessObject das andere dein Defintionsobject was nur zur Datenhaltung dient.
Ich kenne PWA von P.Lorenz nicht. Aber ich denke es wird auch dort so gemacht.
Alles andere wäre wie oben schon geschrieben nicht empfehlenswert.
Jörg
Es ist auch möglich, die DAL Logik in die Klasse (z.B. User) zu verschieben (Factory Methode).
Das ermöglicht trotzdem noch eine Abstrahierung der zugrunde liegenden Daten und/oder die Trennung auf verschiedene Tiers.
Selbstverständlich hat diese Variante auch Nachteile, aber die Tatsache nur eine Klasse zu haben (und dadurch keine doppelte BL) gefällt mir.
Gruss Fellmer
Klar geht das!
public class User
{
// Fields & Propeties
public User(Guid userid)
{
this.username = dr.GetString(0);
}
}
Es immer ne Frage welche Lösung für das Projekt die "Richtige" ist.
Jörg
Hallo Jörg
Ich glaube du hast mich missverstanden, mein Beitrag war keine Frage 🙂
Dein Beispiel würde jedoch nicht in mein Konzept passen, denn eine zusätzlicher Tier (z.B. Applikationsserver / DAL) müsste in diesem Falle Kentniss von der Klasse user haben (Parameter für Konstruktor).
Und das ist ja genau das was ich vermeiden will.
Hmm... vieleicht habe ich auch dich missverstanden 🤔 😉
Gruss Fellmer
Ich habe Beitrag auch nicht als Frage verstanden, sondern die Aussage nur kommentiert.
Jörg