Akzeptables Klassendesign?
Hallo zusammen,
wir diskutieren gerade eine Problematik, wie ich am effizientesten und übersichtlich meine Objektklassen schreiben kann.
Meine Frage: was spricht dagegen, dies wie folgt zu tun:
Ich habe ein Basisobjekt, von dem alle meine Objektklassen erben.
Dieses enthält eine DataRow-Member, die quasi als Container für meine Objekte fungieren soll.
public abstract class BasisObjekt<T>
{
protected DataRow mDataRow;
}
Die Klasse Kunde sieht abgekürzt ungefähr so aus:
public class Kunde:BasisObjekt<Kunde>
{
public string Nachname
{
get {return mDataRow["Nachname"].ToString()}
set {
mDataRow["Nachname"]=value;
}
}
}
Somit umgeh ich das Umschaufeln beim Einlesen der Daten in die Properties, kein Zurückschaufeln beim Speichern, kein Reinschaufeln bei Aktualisierung.
Außerdem hat das DataRow von Haus aus schon alle Ereignisse implementiert, die ich gebrauchen könnte (Column, Row .. Changing, Changed).
Außerdem habe ich beim Abrufen der Daten von der Datenbank keine Konvertierungsproblematik, das Datentyp etc in den Columns auch schon korrekt gespeichert sind.
Bin für jede Meinung dankbar.
Katja
Also was ich noch nich ganz verstehe ist, warum deine Basisklasse eine generische Klasse ist und die davon abgeleitete Klasse kennt.
public class Kunde:BasisObjekt<Kunde>
Aber ansonsten ist das mit dem protected geschützten Feld normal und ich würde es genauso machen.
Es gibt 3 Arten von Menschen, die die bis 3 zählen können und die, die es nicht können...
Ja danke.
Ich reiche doch den Typ an die Basisklasse weiter.
Damit habe ich alle Methoden, Properties und Ereignisse ausgelagert, über die alle meine Objekte verfügen sollen.
Wie:
public abstract class BasisObject<T>:IClonable, ISerializable, IBasisObjekt
{
... IBasisObjekt-Member
... Clonerei
... Serialisierung
}
Die IBasisObjekt-Schnittstelle brauche ich, damit ich wieder an mein DataRow komm.
Oder hab ich jetzt was falsch verstanden?
Katja
Normal sollte eine (abstrakte) Basisklasse nicht wissen, von wem sie abgeleitet wurde.
Kannst du rein aus interesse halber mal den Quelltext der Klasse Basisobjekt posten?
Es gibt 3 Arten von Menschen, die die bis 3 zählen können und die, die es nicht können...
Jo, hier, bitte ... Allerdings bin ich kein Held, was C# angeht, wird hoffentlich mal...
using System;
using System.Collections;
using System.Collections.Generic;
using System.Text;
using System.Data;
using System.ComponentModel;
using System.Runtime.Serialization;
namespace MyProjectObjects
{
public abstract class ObjectItem<T> :ICloneable, ISerializable,IObjectItem
{
#region protected Member
protected DataRow mDataRow = null;
#endregion
#region private Member
private bool mAck;
#endregion
#region öffentliche Properties
public bool Ack
{
get { return mAck; }
set { mAck = value; }
}
#endregion
#region Serialisierung
//Methode die während Serialisierung aufgerufen wird
public void GetObjectData(SerializationInfo info, StreamingContext context)
{
foreach (DataColumn dc in mDataRow.Table.Columns)
{
info.AddValue(dc.ColumnName, mDataRow[dc.ColumnName]);
}
}
#endregion
#region Konstruktor für Deserialisierung
protected ObjectItem(SerializationInfo info, StreamingContext context)
{
foreach (DataColumn dc in mDataRow.Table.Columns)
{
mDataRow[dc.ColumnName] = info.GetString(dc.ColumnName);
}
}
#endregion
#region Konstruktor
public ObjectItem()
{
//throw new System.NotImplementedException();
}
#endregion
#region IClonable Members
/// <summary>
/// Erzeugt eine exakte Kopie des Objekts (flach)
/// </summary>
/// <returns>Kopie des Objekts</returns>
object ICloneable.Clone()
{
return this.MemberwiseClone();
}
#endregion
#region Object ID Value override
protected abstract object GetIdValue();
#endregion
#region System.Object overrides
public override bool Equals(object obj)
{
if (obj is T)
{
object id = this.GetIdValue();
if (id == null)
throw new ArgumentNullException();
return (obj as ObjectItem<T>).GetIdValue().Equals(id);
}
else
return false;
}
public override int GetHashCode()
{
object id = GetIdValue();
if (id == null)
throw new ArgumentNullException();
return id.GetHashCode();
}
public override string ToString()
{
object id = GetIdValue();
if (id == null)
throw new ArgumentNullException();
return id.ToString();
}
#endregion
#region IObjectItem Member
DataRow IObjectItem.ObjectDataRow
{
get
{
return mDataRow;
}
set
{
mDataRow=value;
}
}
#endregion
//#region IObjectItem<T> Member
//T IObjectItem<T>.CreateInstance(DataRow dr)
//{
// throw new Exception("The method or operation is not implemented.");
//}
//#endregion
}
}
Sehe ich das richtig? du brauchst das Generik T nur um zu vergleichen ob zwei Klassen identisch sind?
public override bool Equals(object obj)
{
if (obj is T)
{
object id = this.GetIdValue();
if (id == null)
throw new ArgumentNullException();
return (obj as ObjectItem<T>).GetIdValue().Equals(id);
}
else
return false;
}
das würde ich zum Beispiel
public override bool Equals(object obj)
{
if (obj is ObjectItem)
{
object id = this.GetIdValue();
if (id == null)
throw new ArgumentNullException();
return (obj as ObjectItem).GetIdValue().Equals(id);
}
else
return false;
}
schreiben. oder für was war T in der Klasse noch gedacht?
Es gibt 3 Arten von Menschen, die die bis 3 zählen können und die, die es nicht können...
Hi,
ja, siehst du richtig. Seh ich auch grad, dass das Quatsch ist.
Danke dir.
Allerdings: abstract war wegen der Methode
protected abstract object GetIdValue();
notwendig.
Gegen das Abstract sag ich nix. nur das Generic T war mir bissel suspekt.
Es gibt 3 Arten von Menschen, die die bis 3 zählen können und die, die es nicht können...
Nee, is ja auch super, wenn mal jemand anders drüber schaut.
Hab den generischen Typ raus, weils ja wirklich keinen Sinn hier macht.
Danke.
Katja
Jetzt muss ich doch noch mal einhaken.
Es stimmt schon, dass eine Basisklasse nicht wissen sollte, von wem sie abgeleitet wurde. Allerdings tut sie das hier ja auch nicht.
Der Objekt wird ja durch <T> repräsentiert.
Katja
Deine Klasse ObjectItem kennt das Objekt System.Object. Aber System.Object kennt nicht deine Klassee ObjectItem. Genau das hast du unten mit dem Generic T gemacht.
Es gibt 3 Arten von Menschen, die die bis 3 zählen können und die, die es nicht können...
Hm, danke für deine Meinung.
Ich verstehs net wirklich.
System.Object muss ja meine Klasse nicht kennen, solls ja auch net.
Außerdem is doch jede Klasse von System.Object abgeleitet.
Kann gut sein dass ich den Wald vor lauter Bäumen nicht seh.
Aber jeder, der ToString, Equals .. schon mal überschrieben hat, arbeitet doch mit System.Object.
Ich seh schon den Punkt, dass ich keine generische Klasse gebraucht hätte, hab ich auch geändert, aber mit der Begründung, dass meine Klasse System.Object kennt, ja freilich ...
Egal, ich les nochmal nach.
Danke dir.
Hallo Katja,
Somit umgeh ich das Umschaufeln beim Einlesen der Daten in die Properties, kein Zurückschaufeln beim Speichern, kein Reinschaufeln bei Aktualisierung.
Ich hab´nicht so recht verstanden, wo Du das genau "umgehst", denn **jede **abgeleitete Klasse muss ja genau das machen: Die veröffentlichten Properties jetzt in Feldnamen umleiten und der DataRow der Basisklasse entnehmen.
Wir haben etwas ähnliches gemacht und verwenden aber einfach einen Indexer, um auf die Feldnamen draufzukommen.
Das mag vielleicht hinsichtlich der Typsicherheit Einbußen bringen, aber an der Stelle, wo man auf die Eigenschaften einer Klasse draufwill, muss man als Programmier ja eh wissen was man tut 😉
Auf Dein Beispiel bezogen sähe das dann wohl so aus:
public class BasisObjekt<T>
{
public object this[string fieldName]
{
get { return mDataRow[fieldName]; }
set { mDataRow[fieldName] = value; }
}
}
Die abgeleiteten Klassen müssen jetzt hinsichtlich der Properties gar nichts mehr machen.
Und bei der Verwendung sieht´s dann so aus
Kunde customer = new Kunde();
string Nachname = customer["Nachname"].ToString();
float Umsatz = (float)customer["Umsatz"];
hth, gruß
Ron
Guten morgen erstmal nach Nürnberg😉
Original von kat_2403
Hm, danke für deine Meinung.
Ich verstehs net wirklich.
System.Object muss ja meine Klasse nicht kennen, solls ja auch net.Außerdem is doch jede Klasse von System.Object abgeleitet.
Kann gut sein dass ich den Wald vor lauter Bäumen nicht seh.
Aber jeder, der ToString, Equals .. schon mal überschrieben hat, arbeitet doch mit System.Object.
Ich seh schon den Punkt, dass ich keine generische Klasse gebraucht hätte, hab ich auch geändert, aber mit der Begründung, dass meine Klasse System.Object kennt, ja freilich ...
Egal, ich les nochmal nach.
Danke dir.
Ja genau. du hast es richtig gesagt, du kannst mit der abgeleiteten Klasse auf die Funktionen, Eigenschaften, Felder, Konstruktoren etc. der Basisklasse zu greifen, ggb. falls überschreiben und die Funktionen neu implementieren.
Die Basisklasse hingegen kann/sollte nicht auf die Member von der ihr abgeleiteten Klasse zugreifen (können).
Beispiel.
Du kannst die Funktion ToString() von System.Object in deiner Klasse aufrufen. System.Object kann aber nicht deine Eigenschaft Ack aufrufen.
Es gibt 3 Arten von Menschen, die die bis 3 zählen können und die, die es nicht können...
Guten Morgen Ron,
Somit umgeh ich das Umschaufeln beim Einlesen der Daten in die Properties, kein Zurückschaufeln beim Speichern, kein Reinschaufeln bei Aktualisierung.
Ich meinte damit, dass, wenn ich intern immer nur mit einem DataRow-Objekt arbeite, und meine Klassen auch, dann kann ich auf das Schreiben der Properties a la
private string mName;
public string Name
{
get{return mName;}
set
{ mName=value;}
}
verzichten...
Ich arbeite dann immer nur mit der entsprechenden Column meines DataRow-Objekts...
also so:
public string Name
{
get{return mDataRow["Name"];}
set
{ mDataRow["Name"]=value;}
}
Für mich liegt der Vorteil eher im holen der Daten.
Ich hole mir ein DataTable von der Datenbank. Wenn ich dann eben direkt mit den Rows als "Objekten" arbeite, muss ich nicht jede Spalte in das Objekt konvertieren.
Wie z.B. eine Funktion ConvertToObject
Kunde.Name=(string) mDataRow["Name"];
Diese Zuweisung entfällt somit, und ich spar mit n Haufen Schreibarbeit.
Kann gut sein, dass ich das später wieder einbüse, aber bis jetzt ist mir nix aufgefallen.
Dein Ansatz sieht für mich gut aus. Wäre zu überlegen, ob man es auch so macht.
Grüße
Katja
Hallo kat_2403,
ob du intern einzelne Instanzvariablen oder eine DataTable benutzt, kannst du dir nach Belieben aussuchen. Die Implementierung einer Klasse ist frei. Wichtig ist die Schnittstelle nach außen und die ist ja in beiden Implementierungvarianten gleich. Du kannst also ruhig deine DataTable verwenden.
herbivore
Guten Morgen Katja,
da mir Dein Ansatz wie gesagt ziemlich bekannt vorkommt, hier noch ein anderer Denkanstoß:
Wir hatten zu Beginn unseres Framework-Designs so etwas wie BusinessObject´s, wo ebenfalls das einzelne Objekt für seine Datenbeschaffung und -speicherung verantwortlich war.
Im Rahmen eines sehr effizienten Workshops im Dezember hat uns Ralf Westphal darauf gebracht, dass es ggf. viel sinnvoller ist, aus BusinessObject einen BusinessContext zu machen: eine Klasse, die eben nicht nur eine Tabelle sondern ein ganzes DataSet enthält, in dem jeweils alle zu verarbeitenden Daten eines Geschäftsprozesses drin sind.
Seine Argumentation war, dass DataSets klein und billig sind und dass eine durchschnittliche Datenbank heutigen Standards sich freut, wenn sie ausreichend zu tun bekommt 🙂
Beispiel: In der GUI soll ein Mitarbeiter mit seiner Anschrift, Unternehmensrolle etc. bearbeitet werden. Der BusinessContext "Mitarbeiter" enthält jetzt ein DataSet mit den Tabellen MITARBEITER, PERSON, ADRESSE, KONTO, TELEFON, AKTIVITAET.
Ausserdem kennt sein DataSet die Beziehungen der Tabellen untereinander und weiß diese zu verarbeiten bzw. zu berücksichtigen: Ein neuer anzulegender Mitarbeiter bspw. erzeugt seine eigene GUID und kann bereits alle Detaildaten in die abhängigen DataTables ebenfalls einfügen, bevor eine Kommunikation mit der physikalischen Datenbank nötig ist.
Wir haben diesen Vorschlag beherzigt und können nur gutes davon berichten.
Anbei mal das Geheimnis unseres Erfolgs als Diagramm 😉
Vielleicht bringt Dich das auch nochmal auf neue Ideen...
Liebe Grüße
Ron
Hi Ron,
den Ansatz find ich gut, muss ich mir genauer anschaun.
Ahm, wir gestalten das ein bisschen anders, in dem wir "fette", oder sagen wir "erweiterte" Objekte haben.
D.h. Kunde hätte Instanzen von ADRESSE, oder BESTELLUNGEN an sich gespeichert.
Wenn wir das nach deinem Ansatz gestalten würden, würden wir glaub ich unserem Framework a la SOA nicht ganz gerecht werden.
Ich muss mir das jetzt aber noch mal genauer anschauen, was ihr da kreiirt habt.
Danke dir.
Hi citizen.ron,
weißt du ob Ralf Westphal etwas zu dem Theme veröffentlicht hat? Würde mich sehr interessieren. Sieht jedoch laut Google nicht danach aus.
Bei deinem Beispiel hält der BusinessContext "Mitarbeiter" also alle für den Mitarbeiter relevanten Daten?
Hallo citizen.ron,
schliesse mich langalaxy an und würde micht auch sehr freuen über mehr Informationen/Material oder Beispiele.
Gruß falangkinjau
Guten Morgen Ron,
Deinen Ansatz finde ich sehr interessant.
Ich arbeite momentan auch mit BusinessObjects (also Dein erster Entwurf).
Leider macht sich das dafür notwendige "Umschaufeln" der Datensätze bei großer Anzahl, aus Performance-Sicht doch bemerkbar.
Allerdings würde ich aus Gründen der Wartbarkeit und Transparenz immer noch an dem Konzept festhalten.
Ein weiterer Punkt ist die Tatsache, dass die Daten beim Laden in die BusinessObjects noch nach Vorgaben der Geschäftslogik vorverarbeitet/manipuliert werden müssen, bevor sie an generalisierte Komponenten weitergereicht werden (z.B. einen PDF Generator o.ä.).
Wenn ich Dich richtig verstanden habe enthält Dein DataSet im BusinessContext ja die Rohdaten aus der Datenbank, oder?
Gruß,
Nils
Ooops,
gleich so viel Resonanz... 😉
@langalaxy:
Ralf Westphal hat meines Wissens nach nicht explizit zu dem Thema BusinessContext vs. BusinessObject veröffentlicht, da wir uns in einen firmenspezifischen Workshop eingebucht haben und mit ihm unser Framework diskutiert haben, in diesem Rahmen eben nur obengenannter Verbesserungsvorschlag, der dann weiter ausgearbeitet wurde.
@gollum9
Ein weiterer Punkt ist die Tatsache, dass die Daten beim Laden in die BusinessObjects noch nach Vorgaben der Geschäftslogik vorverarbeitet/manipuliert werden müssen
@falangkinjau
und würde micht auch sehr freuen über mehr Informationen/Material oder Beispiele.
Wie aufbereitet oder roh die Daten in das BusinessContext-Objekt gelangen, ist bei uns Aufgabe der Datenlogik und die ist komplett in der Datenbank SQL Server 2005.
Wir haben keine einzige SQL Anweisung im Code; Jeder BusinessContext kommuniziert über Stored Procedures mit der Datenbank. Dabei verwenden wir die Schemata des SQL Servers im wesentlichen auch zur Aufteilung in Anwendungsmodule.
Beispiel:
Das Datenbank-Schema "PM" (für "Projektmanagement") hat alle möglichen Tabellen und Stored Procedures.
Eine Anwendungsview PM hat alle GUI Ansichten zu dem Schema und wird kompiliert in eine [Projektname].PM.dll.
Eine Geschäftsschicht PM.Business hält die Geschäftslogik und damit alle Implementierungen der Schnittstellen und wird kompiliert in [Projektname].PM.Business.dll.
Die Schnittstellen selbst schließlich befinden sich alle in einer gemeinsamen Bibliothek [Projektname].Contracts.dll.
Der Vorteil des BusinessContext liegt meiner Meinung nach bspw. auch in folgendem tabellenübergreifenden Sachverhalt:
Nehmen wir das Szenario an, dass zu einem neuen Kunden automatisch ein Buchungskonto angelegt werden soll. Ausserdem darf er nicht gespeichert werden, wenn nicht mindestens eine Adresse angegeben wurde.
Der BusinessContext enthält nun folgende Tabellen: (s. Bild)
Dabei enthält die "Haupttabelle" natürlich immer nur einen Datensatz (hier: einen Kontakt).
Der Kontext bietet, wie ihr in vorigen Diagramm seht die Methode Save an, um die Daten in die Datenbank zu schreiben.
Save geht aber nur, wenn IsValid = true, und wann sie gültig ist, entscheidet die jeweilige Kontextimplementierung eben aufgrund ihrer Geschäftslogik.
In diesem Falle würde der Kundenkontext eben Save nicht erlauben, wenn zu dem neu angelegten Kontakt nicht mindestens auch ein Eintrag in KONTO, PERSON und ADRESSE erfolgt sind.
hth, gruß
Ron
Danke erstmal für die ausführliche Auskunft.
Find ich echt geil, dass Du Dir ohne eigenes Interesse soviel Zeit nimmst uns das zu vermitteln!
Wie aufbereitet oder roh die Daten in das BusinessContext-Objekt gelangen, ist bei uns Aufgabe der Datenlogik und die ist komplett in der Datenbank SQL Server 2005.
Hm, aber das bedeutet doch, dass die Geschäftslogik im Datenbank-Layer realisiert ist, oder?
Um meinen Standpunkt verständlich zu machen kurz ein Beispiel:
Man entwickelt eine Statistik Komponente, die einfache bis sehr komplexe Statistiken erzeugt in div. Ausgabeformaten.
Dabei werden z.B. Mittelwerte berechnet, prozentuale Werte uvm. (GL) und dann alles (als BO) an z.B. den PDF Generator geschickt der des Weiteren noch einen Definitionssatz mit Layout-Informationen bekommt und alles in eine Tabelle haut.
So, die Geschäftslogik führt also diverse Berechnungen aus, bereitet die Daten auf z.B. auch Kürzung von Float-Zahlen auf 3 Nachkommastellen (inkl. Globalisation/Localisation) und packt alles in ein BusinessObject, welches dann je nach gewünschter Ausgabeart als Schnittstelle zwischen den Komponenten weitergereicht wird.
Wie würde man das mit Deinem Design auf Basis des IBusinessContext verbinden können?
hi gollum,
konkret im Zusammenhang mit Deinem Beispiel bin ich nicht sicher, ob das bei uns einen BusinessContext "wert wäre".
Der BusinessContext soll ja insbesondere auch die Aktualisierung von Daten handhaben.
In deinem Beispiel habe ich das Gefühl, dass es mehr um Reporting geht.
Anyway, Aufbereitung der Daten inkl. Nachkommastellenkürzung etc. würde ich noch immer auf Stored Procedure Ebene lösen.
Ich würde auf jeden Fall immer dafür sorgen, dass Daten so aufbereitet wie möglich in meinen Programmen ankommen.
Wenn ich auf Dein Beispiel einen BusinessContext anwenden würde, dann wenn z.B. die erstellten Berichte/Statistikdaten in dieser aufbereiteten Form persistent bleiben sollen oder wenn die Art der Aufbereitung mit SQL einfach nicht machbar wäre.
hth
ron
Find ich echt geil, dass Du Dir ohne eigenes Interesse soviel Zeit nimmst uns das zu vermitteln
Sozialfimmel 😁
Sagen wir´s mal so: Heute ist einer dieser Tage, wo alles was ich im Projekt anpacke, nur zu Verschlimmbesserungen führt - da mach ich mich doch lieber hier nützlich... 😉
Hi Ron,
also auch noch mal ein Danke von mir.
Mir gefällt das immer besser, vor allem, weil wir ähnlich arbeiten:
- keine sql statements im code
- datenabruf mit SPs
Wir wollten unbedingt verhindern, dass der Entwickler der grafischen Oberfläche, schreibenden Zugriff IDs, GUIDS hat, bzw. diese manipulieren kann. Ist so auch ein schöner Ansatz.
Ich hatte oben gesagt, dass das evtl für uns nicht in Frage kommt, mit einem Context zu arbeiten, da wir nicht komplett alles in einem Objekt erschlagen wollen, also es gibt auch Kunden ohne Bestellung. Aber ich seh, die Defintion des Contextes ist ja eh mein Bier.
Katja
Hallo citizen.ron,
besten Dank für die Erläuterung. 👍
Gruß falangkinjau
Sagen wir´s mal so: Heute ist einer dieser Tage, wo alles was ich im Projekt anpacke, nur zu Verschlimmbesserungen führt - da mach ich mich doch lieber hier nützlich... 😉
*g - dann wollen wir mal hoffen, dass dieser Zustand noch möglichst lange anhält 😉
Back 2 Topic:
Der BusinessContext soll ja insbesondere auch die Aktualisierung von Daten handhaben.
Ok, jetzt bin ich bei Dir 😉
Ja, Reporting triffts auf den Punkt.
Ist allerdings nur ein Modul der zu entwickelnden SW, von daher überlege ich jetzt das BusinessContext Konzept in den Modulen einzusetzen wo die Anforderungen es ermöglichen/erfordern.
Da wir uns momentan am Ende des Prototyping befinden ist es jetzt noch möglich solche zentralen Entwurfsentscheidungen zu überdenken.
Allerdings war für mich ja gerade die Performance die Motivation etwas umzustellen - die wird allerdings gerade im Reporting benötigt^^
Wie weit ist denn Dein/Euer Projekt?
Und in welcher Größenordung in MT ist es angesiedelt?
Es handelt sich um eine komplette Neuentwicklung/Redesign?
BTW: Hat jemand schon Runtime Profiling von C# Applikationen betrieben? Wenn ja mit welchen Tools?