Re: Grundsatzfrage zum Klassen-Design

From: Carsten Posingies (c.posingies_at_gmx.de)
Date: 07/30/04 

Date: Fri, 30 Jul 2004 09:38:51 +0200

Immo Landwerth <mail_ignored@web.de> schrieb:

>> public Person Neu(string name, DateTime geburtstag)
>> {
>> Person p = new Person();
>> p.Name = name;
>> p.Geburtstag = geburtstag;
>> string[] ary = name.Split(" ".ToCharArray());
>> string vorname = ary[0];
>> string nachname = ary[1];
>> Guid guid = Guid.NewGuid();
>> string sql = "INSERT INTO Persons ( ID, FirstName, LastName,
>> Birthdate)
>> VALUES ( " + guid + ", '" + vorname + "', '" + nachname +
>> "', #" + geburtstag.ToString() + "#";
>> // dataadapter, dataset, datatable, datarow,
>> // dataconnection, oledbcommandbuilder, bla...
>> }
>
> So in etwa hatte ich mir es vorgestellt, ja.

So, und jetzt mache ich eben 1:1-"Relations" zwischen Tabellen und
Klassen daraus. 1 neues Feld = 1 neues Mitglied + 1 neuer Zugreifer
(VS.NET-Makros bestellen schöne Grüße, sprich: "private <type> <name>"
eingetippt, Makro aufgerufen, Zugreifer der Optik halber verschoben,
fertig ist die Laube).

>>> Das schöne an Interfaces ist dann ja, dass Du sie nicht ändern
>>> kannst, ohne dass der Compiler sich beschwert. Deswegen: Mut zum
>>> Refactoring.
>>
>> Mut zum Refactoring immer. Was Interfaces betrifft, ist das
>> Meckern des Compilers aber irgendwie das Einzige, was ich ihnen
>> abgewinnen kann. Aber das ist ein anderes Thema ;-)
>
> Daraus höre ich, dass Du eindeutig aus der Welt ohne GC kommst -
> also nicht Java oder vergleichbares.
>
> Meiner einer kommt von C++ bzw. Delphi. Dort waren Interfaces
> nicht wirklich das, was ich wollte. Aber unter C# bin ich mir als
> zufrieden mit ihnen.
>
> Just FMI: Was stört Dich an ihnen?

Ich komme, wenn ich überhaupt irgendwo her komme, dann aus der groben
Richtung "einiges an C++" plus "reichlich viel PHP" plus "alles, was
sonstwo nicht geht, geht in 'C'". Außerdem leide ich schon seit
VB6-Zeiten unter Interfaces. Interfaces haben für mich dort einen
(undebattierbaren) Sinn, wo es um Versionskontrolle geht. Aber dieses
laufende "ich definiere mal ein Interface, damit der Compiler
rumnörgelt, wenn ich irgendwas, entspannt und zugekifft, wie ich bin,
implementiere, was eigentlich anders sein sollte..." geht mir tierisch
auf den Zünder.

Sagen wir es mal so: Wer nie in PERL programmiert hat, mag an Interfaces
(d.h. dem Gequengele des Compilers) hängen. Wer es hat, sollte um den
Segen von regulären Ausdrücken wissen -- und sollte über das Feature des
Editors, reguläre Ausrücke zum Suchen von Quellcode-Zeilen zu benutzen,
informiert sein. Zwar sind die regulären Ausdrücke vom VB.NET nicht
gerade "Industrie-Standard" (weil das die von PERL sind, believe it or
not), aber sie funktionieren. Mit ein wenig Geduld und Gelassenheit
gegenüber dem M$'schen Charme kriegt man das in den Griff und baut eben
so lange an den Regex-en rum, bis sie stimmen -- oder steigt parallel zu
allen Segnugen vom VS.NET auf einen andere Editor um, der vernünftigte
Regex-en versteht (TextPad z.B.).

> Für die meisten Projekte wäre das allein schon ein Fortschritt.
> Die meisten befüllen die Tabellen schließlich direkt aus den
> Event Handlern der GUI :)

Aua. Wieder ein tolles Feature vom VS.NET: "DataBinding"! Wie sprach
jener Song-Text von Kate Bush: "'What say you, good people?!' --
'Guilty! Guilty! Guilty!' - 'Yes... burn! Burn, which, burn!'"

>> Aber nochmal zurück zu unserem gemeinsamen Beispiel "Kunde will
>> was, das zu einer Änderung von 1:n zu m:n führt"! Es ist doch
>> sicher klar, dass sich so eine Änderung zwangsläufig quer durch
>> alle Tiers zieht, weil es dem Kunden ja eben wurscht ist
>> (jedenfalls meistens), wie die Daten gespeichert werden, solange
>> er in der Anwendung sieht, was er will. Bleiben wir bei den
>> EMails:
>>
>> - Bisher war jede EMail genau einer Person zugeordnet (Feld
>> "PersonPID" in der Tabelle "Emails"). Jetzt machen wir eine
>> m:n-Zuordnung draus, sodass es eine neue Referenz-Tabelle
>> ("xPersonsEmails") gibt mit drei Feldern: "ID", "PersonPID" und
>> "EmailPID". Nun musst Du doch eindeutig Dein
>> IEmailManager-Interface anfassen, oder etwa nicht? Und
>> darüberhinaus Deine Klasse MyEmailManager!
>
> Exakt. Das Problem an solchen Änderungen ist ja oftmals gar
> nicht, dass es sich durch alle Tiers ziehen, sondern dass man
> nicht alle Stellen enstsprechend der Änderung anpasst. Das liegt
> i.d.R. schlicht daran, dass irgendwo in den Untiefen der BL (oder
> ehrlich gesagt dem Client) SQL Statements liegen, die nicht
> angepasst wurden.

Sorry, dazu fällt mir nur ein "Ätschibätsch!" ein....

> Bei Dir wären dass auch die Klassen, die mittels Reflection
> automagisch auf Tabellen der DB gemapped werden.

Das ist richtig, aber wenn ich irren Spaß daran hätte, würde ich mir das
als Add-On ins VB basteln (Klick auf die Tabelle, fertig ist die
Klasse). Da ich lieber Geld verdiene, pflege ich die Konsistenz mit der
Hand, und zwar in genau einer einzigen Source-Datei, wo ich alle
DAL-Entity-Klassen zusammenstelle.

> Das Hauptproblem an solchen Abhängigkeiten liegt darin, dass man
> sie nur durch gründliche Source Recherche oder per "Ups!"-Effekt
> zur Laufzeit findet. Sie sind nicht durch den Compiler zu finden.

Gut, das zu wissen. Mir ist der Compiler als Source-Debugging-Tool
nämlich ausgesprochen suspekt...

> Mit meinem Vorschlag erreicht man sicher kann 100 % Abhänhigkeit
> von den Daten (was m.E. im Ansatz auch grober Unfug wäre) sondern
> eine gezielte Verlagerung der Problems und quasi Nebenbei ein
> gewisse Unabhänigkeit vom Speichermedium.

Ja, sicher, aber ob ich nun "DataAdapter.Update()" oder
"DataSet.WriteXml()" aufrufe, ist eine Frage des Feintunings.

> Natürlich musst Du den Code in den Interfaces und Managern
> gleichermaßen anpassen. In der Praxis wird man aber wohl nicht
> mehr als zwei Manager haben, so dass der Arbeitsaufwand im Rahmen
> bleibt.

Okay, die Anpassung meiner Variante zieht sich durch das DAL (Tabelle
geändert = Klasse geändert) und durch die BL/D(A)L-Schnittstelle. Das
könnten in der Tat ein paar mehr Quellcodes sein, da die BL-Objekte die
auf der Änderung des DAL basieren, mehr als 1 mächtig sein können.

> Zugegeben, der Code innerhalb der Manager, ist natürlich nicht
> ohne weiteres durch den Compiler kontrollierbar (SQL im String),
> weswegen ich auch stark auf SPs baue.

Ich baue lieber auf die Akribie des Entwickels. Wer damit nicht leben
kann, nunja...

CP

Relevant Pages

  • Re: Grundsatzfrage zum Klassen-Design
    ... Dass, wenn sich Tabellen ändern, sowohl Du als auch ich in den Code ... Sicherlich haben Interfaces ihren Zweck. ... den Compiler zum Generieren von Fehlermeldungen zu bewegen. ... weil mich SPs nun endgültig auf eine DBE festnageln. ...
    (microsoft.public.de.german.entwickler.dotnet.csharp)
  • Re: Apple IIGS ROM 1 or ROM 3, which is better?
    ... of the *simple* indirection cost can be amortized, but compiler ... and every methodology has a terrible dark side. ... code with firm interfaces allowing isolation and factorization. ... the most demanding design activities. ...
    (comp.sys.apple2)
  • Re: object system...
    ... for example, my C compiler, for x86-64, emits mangled names. ... we use interfaces against instances / objects, ... Each node participates in three lists. ... Anyway it is not a language popularity contest. ...
    (comp.object)
  • Re: Check a radio button
    ... building systems, which is that you have to keep the compiled code consistent with the ... Key here is that you are thinking that you can enhance interfaces without rebuilding the ... of bugs would simply be due to compiler changes. ...
    (microsoft.public.vc.mfc)
  • Assembly einbinden/Typ ist mehrfach definiert(CS1595)?
    ... einer Änderung an einer solchen Klasse stelle ich auch fest, ... Compiler zur Laufzeit das ursprüngliche Kombilat aus der Assembly verwendet. ...
    (microsoft.public.de.german.entwickler.dotnet.csharp)