Laden...

Setter als internal deklarieren

Erstellt von Naffel9 vor 17 Jahren Letzter Beitrag vor 17 Jahren 3.121 Views
N
Naffel9 Themenstarter:in
54 Beiträge seit 2006
vor 17 Jahren
Setter als internal deklarieren

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?

2.223 Beiträge seit 2005
vor 17 Jahren

moin

du Könntest die jeweiligen Properties als privat deklarieren und per reflection drauf zugreifen

mfg

49.485 Beiträge seit 2005
vor 17 Jahren

Hallo Naffel9,

die Datenbank-Schicht sollte ohnehin nicht auf die Business-Schicht zugreifen.

herbivore

N
Naffel9 Themenstarter:in
54 Beiträge seit 2006
vor 17 Jahren

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.

1.373 Beiträge seit 2004
vor 17 Jahren

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

N
Naffel9 Themenstarter:in
54 Beiträge seit 2006
vor 17 Jahren

Hallo,

Ich habe z.B. ein Objekt User. Dieses Objekt hat ein Property Username, welches nicht geändert werden darf.

484 Beiträge seit 2006
vor 17 Jahren

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

N
Naffel9 Themenstarter:in
54 Beiträge seit 2006
vor 17 Jahren

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?

484 Beiträge seit 2006
vor 17 Jahren
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

N
Naffel9 Themenstarter:in
54 Beiträge seit 2006
vor 17 Jahren

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.

484 Beiträge seit 2006
vor 17 Jahren

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

N
Naffel9 Themenstarter:in
54 Beiträge seit 2006
vor 17 Jahren

So hätte ich dann aber zwei Objekte, oder sehe ich das falsch?

484 Beiträge seit 2006
vor 17 Jahren

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

K
71 Beiträge seit 2005
vor 17 Jahren

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

484 Beiträge seit 2006
vor 17 Jahren

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

K
71 Beiträge seit 2005
vor 17 Jahren

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

484 Beiträge seit 2006
vor 17 Jahren

Ich habe Beitrag auch nicht als Frage verstanden, sondern die Aussage nur kommentiert.

Jörg