Re: Grundsatzfrage zum Klassen-Design
From: Immo Landwerth (mail_ignored_at_web.de)
Date: 07/30/04
- Next message: Immo Landwerth: "Re: Referenz statt Kopie aus einem Array"
- Previous message: Veronika Neufeind: "RE: DataSets über Parameter öffnen"
- In reply to: Carsten Posingies: "Re: Grundsatzfrage zum Klassen-Design"
- Next in thread: Carsten Posingies: "Re: Grundsatzfrage zum Klassen-Design"
- Reply: Carsten Posingies: "Re: Grundsatzfrage zum Klassen-Design"
- Messages sorted by: [ date ] [ thread ]
Date: Fri, 30 Jul 2004 09:00:16 -0700
Carsten Posingies wrote:
> 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).
Jetzt stehe ich vielleicht auf dem Schlauch, aber was willst Du mir
damit sagen?
> > Just FMI: Was stört Dich an [Interfaces]?
>
> 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.).
Harter Tobak.
Also zum einen sind Interfaces für mehr als nur Versionierung bzw.
Validierung durch den Compiler gut. Ich hatte zwar in meinem letzten
Posting den Fokus stärker auf letztes gelegt, aber das ist nicht der
einzige "Gag" an Interfaces.
Natürlich arbeite auch ich mit Regulären Ausdrücken, schon lange bevor
ich zu VisualStudio oder .NET kam.
Aber Dein Posting erweckt den Eindruck, man brauche keine Interfaces,
sofern man mit regulären Ausdrücken umgehen kann. Und das ist einfach
nur großer Käse.
> > 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!'"
Ja. :) Aber das haben viele Leute unter Delphi und VB lange Zeit zum
Volksport gemacht...
> > 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....
Richtig, mit einer vernünftigen Architektur (wie z.B. bei meinem
Vorschlag) wäre das nicht passiert.
> > 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.
Natürlich kannst Du das so machen, aber damit bist auf _einen_
bestimmten Datenprovider festgenagelt.
BTW, SP wirst Du so auch nicht in den Griff bekommen - aber das willst
Du ja auch gar nicht :)
> > 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...
Tatsächlich? Mir ist es lieber der Compiler sagt mir vorher das etwas
nicht funktionieren wird, als wenn ich es selbst zur Laufzeit finden
muss...
> > 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...
Meiner einer baut lieber darauf, dass ich weiß, dass ich Fehler mache
und immer machen werde. Also versuche ich lieber die Fehlerquellen zu
minimieren statt darauf zu hoffen, dass ich akribisch genug sein werde.
-- Immo Landwerth - Visual Studio 2003 - C# - XanaNews 1.16.3.1
- Next message: Immo Landwerth: "Re: Referenz statt Kopie aus einem Array"
- Previous message: Veronika Neufeind: "RE: DataSets über Parameter öffnen"
- In reply to: Carsten Posingies: "Re: Grundsatzfrage zum Klassen-Design"
- Next in thread: Carsten Posingies: "Re: Grundsatzfrage zum Klassen-Design"
- Reply: Carsten Posingies: "Re: Grundsatzfrage zum Klassen-Design"
- Messages sorted by: [ date ] [ thread ]
Relevant Pages
|
