Designer oder nicht Designer?

Hallo all!

Ich wollte hier mal eine Grundsatzdiskussion lostreten zu o.g. Thema. Weil ich stoße des öfteren auf Unwissenheit, Desinteresse, Ablehnung, was diese Programmierwerkzeuge betrifft.

Ist natürlich bischen allgemein, es gibt ja verschiedene Designer, und manchmal hamse gar einen Bug.
Aber meine Erfahrungen mittm Dataset-Designer, DataContext-Designer, Form-Designer, Datenfenster sind i.A. sehr gut.
Manches machense 'n bischen blöde, aber weilses immer gleich blöde machen, kann man da i.A. recht einfach nachbessern.

An prinzipiellen Vorteilen der Designerei sehe ich:*es steckt ordentlich KnowHow in diesen Dingern, hunderte von Mannjahren Entwicklungszeit. *der generierte Code funktioniert. V.a. Schreibfehler in Strings sind ausgeschlossen. Bugs gibts, aber sind extrem selten *der generierte Code folgt einem Schema. Wenn ich also das Design einer Datenbank kenne, kannich mir die Namen und Properties der Business-Objekte ungefähr denken, die der Dataset-Designer davon generieren würde. Das kann sehr nützlich für die Kommunikation sein. *der generierte Code ist ausgelagert. In meinen Codefiles stehen dann die nicht-trivialen Sachen.

[Edit] Ah, nochn positiver Designer-Effekt:*da der Code funktioniert, kann man evtl. lernen, wie man von Hand das gleiche coden kann.

zusätzliche vorteile die ich sehe:

1. vieles an prototypen lässt sich schnell zusammenklicken.
2. man kommt schnell an ein ergebniss
3. es ist bequemer controls gleich visuell zur designzeit zu positionieren
4. anfänger haben es leichter

nachteile die ich sehe:

1. vor allem weil sich anfänger auf den designer verlassen, stoßen sie recht schnell auf unverständniss und fangen an zu fragen wie: "wie füge ich dynamisch erstellte controls ein... usw"
2. der code, der vom designer generiert wird, wird einzig und allein durch ihn verwaltet. will man eine spezielle anpassung vornehmen muss man teile oder gar das komplette generierte herausnehmen (aus der kontrolle des designers) und umkopieren. bei größeren sachen ist das ziemlich friemelig.
3. eben weil sie nur die standardfälle abdecken, kommt es in den meisten ernsthaften projekten vor (zumindest bei mir) das genau ein kleiner teil nicht vom designer unterstützt wird und ich deswegen auf diesen verzichten muss.
4. in erster lienie weiß man nciht was er macht und was passiert. man muss sich erst den code ansehen.

Designer? Was ist das?

Den einzigen Designer den ich nutze ist der WinForms Designer. Den Rest brauch ich nicht, weilder generierte Code kilometer lang ist und in keinster Weise überschaubar. *ich mir immer 100% sicher sein muss, was genau passiert.

Weitere Nachteile*Für wirklich große Projekte nicht einsetzbar. *Kein Lerneffekt bei Anfängern. Schnell klicki-klicki, aber nicht wissen was passiert. *Änderungen am generierten Code sind nur sehr mühsam zu bewerkstelligen.

*Hatte mal ein fertiges Datenbankschema durch den Designer gejagt. Die fertige CS Datei war knapp 3MB groß! Das ist sowas von grottig...

Ja, beim Dataset-Designer tuts weh - der macht (scheints) nicht unter 100 KB Code.
Das sind aber v.a. die TableAdapter, die der produziert. Schmeiß die mal raus, dann isses nur nochn 1/10.

Überschaubar ist son typisiertes Dataset im ObjectBrowser.
Da finden sich dann so fabelhafte Funktionen, wie

KundeRow rwNew = Dataset.Kunde.AddKundeRow(string Name, string Vorname);

untypisiert ginge das wohl:

DataRow rwNew = Dataset.Tables["Kunde"].Rows.Add(object params Args[]);

Du kannst dich verschreiben, die Reihenfolge der Argumente verwechseln, zu viele, zu wenige, ungültige,...
Und typisiert erhält man den Namen:

string KundeRow.Name

untypisiert:

object Datarow["Name"]

noch ein: Verarbeitung von Datarelations, alle Bestellungen eines Kunden:
typisiert:

BestellungRow[] rwBestellungen = rwKunde.GetBestellungRows();

untypisiert:

DataRow[] rwBestellungen = rwKunde.GetChildRows("KundeBestellungRelationName");

Bei ohne Designern sehe ich die Gefahr, daß ohne gscheite Business-Objekte geproggt wird, die diese Zugriffe kapseln.
Grade bei größeren Sachen kriminell.
Jo, und wenn man sich die Businessies selber schreibt, ist man auch mittn paar KB dabei.
Und ob die selbstgebastelten Businessies auch konzeptionell so durchdacht sind, und auch so stringent einem Schema folgen (und keine Schreibfehler!)....

Man muß für Spezial-Anforderungen übrigens nicht unbedingt auf generierten Code verzichten: Man kann die Dinger auch beerben, oder mit partiellen Klassen an Funktionalität erweitern.
(Dann muß man aber gemein aufpassen, wenn man neu generiert, ob dann noch die Erweiterungen passen.)

Designer? Was ist das?

Den einzigen Designer den ich nutze ist der WinForms Designer. Den Rest brauch ich nicht, weil
der generierte Code kilometer lang ist und in keinster Weise überschaubar*.

ich mir immer 100% sicher sein muss, was genau passiert.

Weitere Nachteile

Für wirklich große Projekte nicht einsetzbar.

Kein Lerneffekt bei Anfängern. Schnell klicki-klicki, aber nicht wissen was passiert.

Änderungen am generierten Code sind nur sehr mühsam zu bewerkstelligen.

*Hatte mal ein fertiges Datenbankschema durch den Designer gejagt. Die fertige CS Datei war knapp 3MB groß! Das ist sowas von grottig...

FULLACK.

Am schlimmsten finde ich, dass man nicht weiß, was das Ding im Hintergrund irgendwie zusammenschustert - und meistens ist das ziemlicher Schrott.

Überschaubar ist son typisiertes Dataset im ObjectBrowser.

Ich orientiere mich zu 100% nur über Code. Wenn ich den ObjectBrowser benötige um etwas zu finden, kann etwas nicht stimmen.

Aber ich benutze die typisierten DataSets/DataTables eh nicht. Da gibt es weitaus besseres. War damals nur ein Test, weil ich sehen wollte, ob VS das Datenbankschmema frisst (wobei ich durchaus positiv überrrascht war, allerdings nicht vom Code).

@ErfinderDesRades

für kleine prototypen oder irgendwelche hilfstools ist der designer echt eine unterstützung aber bei größeren und ernsthaften sachen kannst du mir diesen argumenten nicht punkten.

unter anderem nimmt man bei größeren projekten auch starke frameworks, die einem die arbeit abnehmen (z.b. nhibernate).

@khalid

Ich orientiere mich zu 100% nur über Code. Wenn ich den ObjectBrowser benötige um etwas zu finden, kann etwas nicht stimmen. Ja ich fass das generierte Zeugs auchn bischen wie die Framework-Klassen auf, da muß man ja auch mittm OB guggen.

Aber ich benutze die typisierten DataSets/DataTables eh nicht. Da gibt es weitaus besseres. Wassn? - täte mich interessieren. Wahrscheinlich kostet, hm? wieviel?

Wassn? - täte mich interessieren. Wahrscheinlich kostet, hm? wieviel?

alle or-mapper z.b., da diese meist bei weitem mehr features bieten können wie ein typisiertes dataset.

Ausser für Winforms benutze ich keine Designer.

Ich muss auch immer genau wissen was passiert und ich bin mir bei eigenem Code da einfach sicherer.

Gerade bei Datenbank-Funktionen kann man den gewünschten Effekt oft mit nur ein paar Zeilen Code erreichen.

Einmal habe ich zum Testen einen Dataset Designer benutzt, jetzt muss ich alle paar Wochen mehrere Einträge mit Connectionsstring inkl. User und Kennwort unserer Datenbank aus dem Sourcecode entfernen, keine Ahnung wo die immer herkommen.

Bei Datenbankzugriffen arbeite ich mit Objekten, die genauso komfortabel wie Typed Datasets zu handhaben sind und deren Nachteile nicht haben (110.000 Zeilen Code für ein paar Tabellen).

Grüße Bernd

Hallo zusammen

Ich benutze für ASP.NET nie irgendwelche Designer, genau aus den Gründen die genannt worden sind.
Ausnahmen sehe ich bei Dataset- / LINQ-Zeugs. Das geht dann aber eher in Richtung OR / Mapper als herkömmliche Designer die man kennt.

Wichtige Punkte waren für mich noch:

1. Anfänger haben keinen Plan was sie zusammenklicken
2. Der zusammengeklickte Code hat immer schlechtere Qualität in Vergleich was da händisch erreichbar ist
3. Für schnelle Prototypen ist es verziehen

Das war jetzt aus Sicht von ASP.NET + Visual Studio.

Bei WindowsForms habe ich bis jetzt immer mit dem Designer gearbeitet um eine GUI zu kreiern, jedoch für die Details nicht.

Gruss Peter

Hallo ErfinderDesRades

Ja ich fass das generierte Zeugs auchn bischen wie die Framework-Klassen auf, da muß man ja auch mittm OB guggen.

Geht doch auch gut per Reflector.
Dieser Code ist auch überschaubar und da steckt auch menschlicher Arbeit dahinter. Das ist nicht zu vergleichen mit generiertem Code.

Gruss Peter

Wassn? - täte mich interessieren. Wahrscheinlich kostet, hm? wieviel?

Zur Zeit setze ich XPO ein. Und ja, es kostet nicht unbedingt wenig, habe aber dafür ein wesentlich mächtigeres Werkzeug als typisierte DataSets.

Nebenbei arbeite ich mich gerade ganz stark in das Entity Framework ein (von MS).

... Für wirklich große Projekte nicht einsetzbar.

Naja, was sind denn wirklich große Projekte? Vielleicht denke ich da im falschen Rahmen aber der WinForm-Designer und der Quellcode-Editor sind meiner Meinung nach immer brauchbar und einsetzbar.

Vorallem der Quellcode-Editor ist sehr gut. Der beschleunigt die Arbeit enorm. Die Problematik des eingeschränkten Verständnis für Anfänger stimmt vollkommen. Es mangelt dann einfach an Verständnis wenn man seinen Lebtag nur mit dem VS arbeitet, da einem einfach sehr viel Arbeit abgenommen wird.

Naja, was sind denn wirklich große Projekte?

da kann man keine klare grenze ziehen aber in jedem meiner projekte hätten wir typisierte datasets als grundlage nicht bedenkenlos einsetzen können. für deren prototypen jedoch heb ich bereits welche eingesetzt.

Salute schlingel

Vorallem der Quellcode-Editor ist sehr gut.

Der hat aber nichts mit einem Designer zu tun, oder welchen meinst du?

Gruss Peter

Hallo zusammen,

naja, ihr wisst ja vermutlich, dass ich keinen Designer benutze und alles selber schreibe, weil ich damit a) schneller bin, b) keinen Einschränkungen des Designers unterliege und c) sauberer strukturierte Programme bekomme. Das ist nur meine persönliche Meinung. Jeder kann das anders sehen. Ich will keinen von der Benutzung des Designer abbringen.

Auch zum Thema: Does Visual Studio Rot the Mind?

herbivore

also ich nehme zur Zeit immer mehr abstand, vom designer, obwohl es bei mir um einiges länger dauert, den ganzen code dann zu schrieben, aber, man weis dann hald einfach, was man reingeschriebn hat, und das ist mir wichtiger als Schnelligkeit.

Hallo zusammen

@herbivore
Eine Webapplikation (wenn auch nur eine kleine) ohne Visual Studio würde auch mir gut tun. 🙂
Ich verstehe dich vollkommen.

Gruss Peter

Hmm, kannes sein, daß durchaus Designer genutzt werden, nur nicht der Dataset-Designer vom VS?
Oder haben XPO und hybernate keine grafischen Oberflächen?

Ich könnte ohne Dataset-Designer gar kein Datenmodell machen, ich brauch sone Visualisierung, die mir die Beziehungen zwischen den Entitäten veranschaulicht.

Das ist übrigens recht interessant: Der Nachfolger vom Dataset ist ja der DataContext.
Was soll sein ein OR-Mapper (ich bin mir nicht gaanz sicher, genau zu wissen, was das ist).
Und hat einen noch feineren Designer. Und der kanns auch umdrehen: Man designt sich sein Datenmodell, und bei DataContext.CreateDatabase() erstellt der daraus die passende SQLServer-Datenbank.
Weil mittm VS eine SQL-DB zu konstruieren schien mir bisher immer eine ziemlich schlimme Strafe für irgendetwas, was man offensichtlich im früheren Leben verbrochen haben muß 😉.

Irgendwie sehe ich da auchn Problem im Forum:
Wenn typisierte Datasets verpönt sind, wie will man dann je über Databinding reden?
Wenn Vorraussetzung dafür ist, daß man erstmal 200 Zeilen Datenobjekt schreibt, sich XPO oder hybernate zulegt, dann wird man natürlich weiter den Listboxen die Items einzeln adden und removen, und den DataGridViews die Rows und so Zeugs.
Halt im Gui an den Daten rummurkeln.
Oder mit Objekten vom Typ object proggen ( this.MyDataset.Tables["Kunde"].Rows[0]["Nachname"] ) (oder hießes "NachName"?)

Ich persönlich finde Designer gut. Einsetzen würde und tue ich diese aber nur zum Testen und in ganz wenigen Fällen auch produktiv, da ich doch lieber Herr meines Quellcodes selber bin und wissen möchte was in meinem Programm denn wo alles passiert.

"Designer" an sich verwende ich derzeit nur das Proxy-Generationstool svcutil.exe (Webreferenz hinzufügen)

Hallo Zusammen,

Ich habe früher auch nur mit dem Designer (WinForms) gearbeitet.
Ich weiß nicht, ob ich was falsch gemacht habe, aber bei einigen Forms hatte der Designer Probleme beim Öffnen.
Spätestens wenn es um abstrakte UserControls / Forms geht, zeigt sich aber ein eklatanter Nachteil im Designer. Oder wenn man keinen Default-Konstruktor hat / bereitstellen möchte.
Klar, man kann natürlich für die Design-Time einfach einen einbauen und eine leere Implementation einer abstrakten Methode mit virtual in der Basisklasse definieren - aber so war das ja eigentlich nicht gedacht. Das ist mir einfach zuviel Aufwand nur für den Designer, zumal man auch daran denken muss, diesen Code später wieder zu entfernen - sonst riskiert man leicht Fehler.

Vor ein paar Monaten habe ich nun angefangen, keine Designer mehr zu verwenden. Das klappt erstaunlich gut!
Meine Forms sehen genauso schön aus, wie mit dem Designer erstellt (ich verwende Dynamic Layout mit Table- und FlowLayoutPanel, AutoSize, Anchor und Dock; Hat irgendwo ein Feeling von CSS für WinForms 😉 ) - und passen sich nun auch ohne Probleme immer der Fenstergröße an (wachsen mit, etc.).
Lokalisierung habe ich mit einer kleinen Hilfsklasse und Satelliten-Assemblies selbst in die Hand genommen. Das funktioniert ebenfalls prima. In diesem Punkt war mir der Designer zu frickelig.

Sicherlich ist es auch zum großen Teil Geschmacks- und Glaubensfrage, aber für mich steht fest: Den WinForms-Designer benutze ich nicht mehr.

Schemas für Datenbanken habe ich bisher immer nur auf Papier entworfen oder on-the-fly erstellt (bis jetzt nur kleinere Projekte). Letztens habe ich ActiveRecord von Castle (bzw. das Castle Framework im Allgemeinen) für mich entdeckt: NHibernate in komfortabel. Bei Bedarf kann ich immer auf die Mächtigkeit von NHibernate zurückgreifen und um Mappings muss ich mich mit den Attributen von ActiveRecord nicht mehr kümmern (schön: Alles im Code, keine separaten Mappings mehr).
Durchweg verwende ich für meine BOs in den Formularen DataBinding und das funktioniert auch hervorragend (ich muss die ListBoxen nicht selbst befüllen 😛 ). Das sollte also auch keine Hürde darstellen.

DataSets habe ich noch nie verwendet und den dazugehörigen Designer auch nicht.
ActiveWriter wäre noch interessant gewesen, um die Arbeit zu erleichtern (stumpfsinniges schreiben von Get- / Set-Properties mit einem Feld und implementieren von INotifyPropertyChanged).

Man muss nicht alles einmal von Hand selbst gemacht haben - aber es schadet auch nicht (wenn man es nicht unbedingt produktiv einsetzt - Frameworks / Libraries sind in der Regel mächtiger und besser getestet), um zu verstehen wie es funktioniert.

Summa summarum: Ich kann nur raten, sich auch mal die Welt außerhalb der Designer-Gefilden anzusehen. Es bietet schon Vorteile und der Code ist IMHO qualitativ hochwertiger.
Aber letztendlich muss es jeder selbst wissen. Nur für Ein- und Aufsteiger halte ich es für sehr sinnvoll, sich mal ein Projekt ohne Designer "anzutun".

Mfg NeuroCoder

Salute NeuroCoder

Danke für deinen Beitrag, sehr informativ 🙂

Nur für Ein- und Aufsteiger halte ich es für sehr sinnvoll, sich mal ein Projekt ohne Designer "anzutun".

Auch Profis ohne nichtDesigner-Erfahrung würde sowas IMO sicherlich gut tun, sei dies WindowsForms oder ASP.NET.

Gruss Peter

Wenn typisierte Datasets verpönt sind, wie will man dann je über Databinding reden?

Wo steht geschrieben, das DataBinding nur mit DataSets funktionieren? Oder ein DataGridView?
Ich verwende genauso DataBindings wie wahrscheinlich jeder andere auch (zusätzlich benutze ich allerdings noch die DevExpress Komponenten). Aber ein DataBinding bezieht sich auf ein Objekt, welches bestimmte Interfaces implementiert. Diese kann man ohne weiteres an die eigenen Businessklassen anhängen.

Achja. Datenbanken designe ich Grundsätzlich im Management Studio. Später, wenn eine Datenbank fertig ist, muss ich die Businessklassen dazu basteln (was ich immer Grundsätzlich von Hand mache). Bevor ich überhaupt nur eine Codezeile zu einem neuen Projekt schreibe, ist die Datenbank schon komplett fertig und durchdesignt.

Wo steht geschrieben, das DataBinding nur mit DataSets funktionieren? Oder ein DataGridView? Das habich nicht gemeint. Ich meine, darüber _reden _- Geht ja gar nicht, weil der andere vermutlich nicht DevExpress oder ManagementStudio hat.
Wenn einer irgendwelches Zeugs im DGV anzeigen will, sagich immer: "Mach dirn typisiertes Dataset, zieh die Tabelle aufs Form - fertg" (ist wirklich so).
Aber ohne das brauchts erstmal einen Abriß über das INotifyPropertyChanged - Interface. Und dann fröhliches BO-Proggen. Und hoffentlich willer nicht auch noch sortieren oder filtern.

@ErfinderDesRades:
Wenn Du dich irgendwann mal mit ORMappern und Codegeneratoren beschäftigst,
dann evtl mal über ActiveRecord und ActiveWriter stolperst wird dir bewusst,
das Du da eben komplett daneben gelegen hast.
Und für Filtern und Sortieren gibt es doch fertige Listen ( such mal bei codeproject nach IBindingListView ).

@Khalid:
Ich mache es anders rum ( wenn ich die Freiheit habe).
Ich erstelle mir die Businessobjekte, und lasse meinen Mapper dann
passend dazu die DB anlegen.
Mit ein paar Macros und Templates ist das schnell passiert.

Ich sehe halt das Problem darin, das bei den Designern, die einen die Arbeit weitgehend abnehmen, viele Verständnisprobleme auftreten (werden). Sicherlich kann ich mir ein DataSet generieren und die Daten mit nur ein paar Zeilen Code in ein DataGridView anzeigen. Ich kann sortieren, filtern und was weis ich alles. Aber das "Warum funktioniert das jetzt und vorallem wie" bleibt den meisten doch verborgen. Und dieses Wissen ist meines erachtens notwenig, um überhaupt später komplexere Projekte und Abläufe zu verstehen/durchzuführen. Aber das ist halt meine Meinung 😉

@FZelle:
Ich glaub so könnte ich nicht arbeiten 🙂

Hallo zusammen,

meine Einstellung zu Designern ist teilweise sehr "gemischt".

Obwohl der WinForms Designer mir schon das ein oder andere Mal totalen Schwachsinn geschrieben und ständig neue Fehler in den generierten Code eingebaut hat, will ich doch nicht auf ihn verzichten. Das heißt jedoch nicht, dass ich nicht auch mal nach InitializeComponent() "Hand anlege" und das ein oder andere Control manuell einfüge.

Designer für WPF nutze ich nicht - XAML schreibt man mit IntelliSense IMHO deutlich schneller und ordentlicher.

Für wirklich nützlich halte ich die Designer für LINQ to SQL und LINQ to Entities - diese generieren monotonen Code, den man selbst nicht wirklich anders schreiben würde (á la [Propertyname] [Getter] [Setter, der noch XXXChanging und XXXChanged Methoden aufruft]). Nur eben deutlich schneller.
Dank der partial Methods in 3.5 ist auch die Erweiterbarkeit kein Problem mehr.

Meiner Ansicht nach liegt der große Vorteil der "neuen" Designer (LINQ to Entities, etc.) darin, dass sie nicht direkt Code generieren, sondern erst XML-Dateien schreiben, aus denen dann Codegeneratoren den Code generieren.
Derartige Kombinationen aus Designern und Codegeneratoren steigern in meinen Augen die Flexibilität und Wartbarkeit von Anwendungen. Bei Bedarf lässt sich auch die XML-Datei manuell anpassen, um Funktionen der Codegeneratoren anzusprechen, die dem Designer unbekannt sind. Andererseits kann man schnell mal dies oder das abändern ohne monoton Code verändern zu müssen, um hinterher herauszufinden, dass vorher alles besser war.

Verbesserungspotential sehe ich in Bezug auf Designer und Codegeneratoren vor allem im Punkt der Fehlerfindung - oft steht man nur vor unzähligen Compilierfehlermeldungen im generierten Code, weil ein einziger Eingabeparameter nicht stimmt und weder der Designer noch der Codegenerator dies merken, sondern einfach "generieren".

Ich sehe halt das Problem darin, das bei den Designern, die einen die Arbeit weitgehend abnehmen, viele Verständnisprobleme auftreten (werden).

Dieser Punkt trifft vor allem zu, wenn der generierte Code sehr komplex ist und sich kaum bzw. gar nicht überschauen lässt.
Zu dem Verbergen von inneren Vorgängen bis hin zur Unverständnis: Nun ja - ich will nicht wissen, wie lange und ausgiebig über "moderne" Techniken des .Net Frameworks wie den Garbage Collector oder den JIT-Compiler diskutiert wurde. Sehr gut kann ich mir vorstellen, dass ihnen viele das Gleiche vorwarfen wie hier den Designern (im Moment zu Recht) vorgeworfen wird.

Irgendwann werden Designer sicherlich so perfekt sein, dass man gar nicht mehr verstehen muss, wie ein gewisser Prozess abläuft, da der Designer alles in eine anschauliche Form bringt, in der man leichter Fehler finden, schneller Änderungen vornehmen und trotzdem genau so viel erreichen kann wie mit "konventioneller" Programmierung.

Zur Zeit kann ich nicht beurteilen, ob das nun gut oder schlecht wäre, da man Fehler in den Designern/Generatoren kaum aufspüren könnte.
Für mich ist es derzeit zum Beispiel faszinierend und ein wenig erschreckend zugleich, wie LINQ to XXX den Code analysiert um aus einem "where c.Name.StartsWith(/**/)" ein korrektes SQL Statement generiert - auch eine Form von einem "Language Integrated Code Generator".

@FZelle

Habich jetzt ActiveWriter installiert, für VS2005 Std Ed.

Ja. Bei den externen Tools erscheint nix, auch nicht im Add-In-Manager, und bei den Project-Templates auch nicht. Mussich Hybernate haben oder ActiveRecord?

Hallo,

Designer sind meiner Meinung nach gut, haben aber auch einige Nachteile. Man muss halt von Designer zu Designer entscheiden, ob seine Vorteile die Nachteile überwiegen.
Zu den wohl bekanntesten Designern (oder zumindest die, die ich kenne):
Windows-Forms-/Web-Forms-/WPF-Forms-/etc. Designer: der generierte Code ist übersichtlich und die visuelle Gestalltung einer visuellen Klasse finde ich nicht verkehrt.
Datenbank-Designer: Spricht eigentlich nichts dagegen, aber eigentlich sollte der Designer überflüssigsein, da man ja eine Software-Designt (OOP) und sich daraus die Datenbank ergibt.
DataSet-Designer: Also ich empfinde diesen Designer als Frefel gegen die Objektorientierung. So etwas verleitet zu "Rapid Programming" und das wiederum verursacht Probleme, wenns um Wartung und/oder Anpassungen geht (oder gar Customizing).

Jetzt zum Thema "Designer ohne DataSets":
Das DataBinding funktioniert auf alle Arten von Objekten, daher kann man es unabhänig vom z.B. O/R Mapper beschreiben. (siehe: SortedList ComboBox ID DataBinding Problem )
Und das Thema "INotifyPropertyChanged", "BindingList" und Co. erfordert nun mal ein mindesmas an Verständniss und Fachwissen, was A) jeder professionelle Entwickler haben sollte (leider nur sollte) und B) ja wie schon angekreidet durch die Designer verloren geht.
Außerdem kann das ganze ja von abstrakten/generisch für alle Klassen implementiert werden und der Entwickler hat es wieder einfacher.

Gruß
Juy Juka

hi

ich benutze n designer eigentlich nur für die (siehe name) design-technischen sachen wie anordnung von elementen auf win-forms und zur benennung der jeweiligen elemente...
bin was design angeht etwas unbegabt...
auch mal son sqldatasource oder n gridview auf ne webseite ziehn... der rest wird aber alles mit handgeschrieben...

es stimmt schon, das son ding die "konfiguration" eines gridviews vereinfacht, aber spätestens als ich mir eine gridview zusammenklicken musste, weil die sachen teilweise kaum über n code erreichbar waren (und wenn dann irgendwie kompliziert), is mir aufgefallen, das man wenn man sowas in grossdem stil benutzt, eigentlich gar nich (oder kaum) mehr programmiern können muss...

ich weiss nich wies es euch geht, aber ich programmiere weils mir spass macht und ich mir nich irgendwas zusammenklicken will...

ich seh das hauptproblem aber darin, dass man beim "zusammenklicken" von anwendungen keinen lerneffekt mehr hat...

_mfg

da der Code funktioniert, kann man evtl. lernen, wie man von Hand das gleiche coden kann.

Dem kann ich zustimmen, ich habe so sehr viel gelernt. Bei ADO.NET verlasse ich mich heute lieber auf meine handmade Künste, bei WPF z.B. nutze ich en VS Designer aber schreibe auch oft den XAML Code selber, manchmal geht das eine schneller, manchmal das andere, optimieren und kontrollieren kann man aber nur den XAML Code.

[...]
Der hat aber nichts mit einem Designer zu tun, oder welchen meinst du?

Gruss Peter

Hoppala, da hab ich wohl unbewusst Designer mit VS gleichgesetzt. Mein Fehler.

ich weiss nich wies es euch geht, aber ich programmiere weils mir spass macht und ich mir nich irgendwas zusammenklicken will...

Also ich möchte nicht jede Arbeit immer selbst erledigen. Besonders beim Oberflächen designen stößt man sehr bald auf wirklich langweilige Arbeiten. Da es is angenehmer sie schnell zusammenzuklicken und sich bei Bedarf eigene Controls zu entwickeln.
(Jedoch sollte ein jeder der den FormsDesigner verwendet auch wissen wie es ohne geht!)

wie herbivore schon erwähnt hat, unterliegen designer immer gewissen einschränkungen. ja, man kann sich alles schön zusammenklicken und mit einem mächtigeren designer kann man uch mehr und mehr zusammenklicken aber wehe denen, die einen spezialfall haben.....
alle spezialfälle kann ein designer nunmal nicht abdecken.

sobald das projekt an größe gewinnt, stößt man andauernd auf spezialfälle. wenn man da nicht weiß, was der designer macht und zur not auch komplett selber machen könnte, dann ist das der supergau für das projekt. deshalb glaube ich nciht, das designer konventionelle programmierung ersetzen könnte.

@ErfinderDesRades
ich kann dir nur ans herz legen dich ein wenig mal mit or-mappern zu beschäftigen. bei nhibernate z.b. schreibe ich mir mein xml-schema, aus dem dann meine datenklassen komplett generiert werden. die muss ich dann nur noch nach meinen bedürfnissen erweitern. genauso verhält es sich mit der datenbank. ich schmeiß den generator an und der generiert mir passend zu meinem schema eine firebird, sql oder irgendeine andere unterstützte datenbank.
zusätzlich kommen dann ncoh die nhibernatefeatures wie z.b. lazy-loading (ein wirklich cooles feature das man mit typisierten datasets so nicht hinbekommen könnte oder besser gesagt nur mit extrem viel aufwand hinbekommen könnte)

Das mag sein, daß Designer nicht alle Spezialfälle abdecken können. Aber eben doch die Standard-Fälle.

@ErfinderDesRades
ich kann dir nur ans herz legen dich ein wenig mal mit or-mappern zu beschäftigen. Ich würd ja gerne. Aber den ActiveWriter kriege ich nicht an, für nhybernate binnich zu knickerig.
Der einzige OR-Mapper, der mir zur Verfügung steht, ist der LinqToSQL-Datacontext.
Leider arbeitet mein SQL-Server nur in Zeitlupe (20s, eine DB zu connecten), der ist aber Vorraussetzung für LinqToSQL.
Vonne Benutzung her sehe ich keinen prinzipiellen Unterschied zu typisierten Datasets. Nur die BOs vom Datacontext sind sauber geproggt, während der generierte Code eines Datasets schon ziemlich gruselig ist.
Aber an der designer-gestützten Arbeitsweise ändert sich nichts durch den Umstieg von Dataset auf DataContext.

Zum Lazy-Loading: Für Dataset habichn DatasetAdapter geschrieben, der das ziemlich allgemeingültig übernimmt. Also DatasetAdapter aufs Form, und dann gibts nur noch DatasetAdapter.Load/Save, und die Tabellen, für die LazyLoading eingestellt ist, die loaden eben lazy.
Beim LinqToSQL-Datacontext ist LazyLoading Voreinstellung. Besonders lustig: Man kann sich die SQL-Commands ausgeben lassen, die der an die DB absetzt.

Den einzigen und fatalen Nachteil von LinqToSQL findich, dasses ohne SQL-Server nix tut. Ein typisiertes Dataset kannich mit WriteXml auf Platte schreiben, das ist bis zu ca. 10MB Datenbanken performanter und Ressourcenschondender als das SQL-Server-Monstrum.

Datenklassen in Xml zu schreiben scheint mir umständlich. Guck, was der LinqToSQL - Designer generiert:

<?xml version="1.0" encoding="utf-8"?>
<Database Class="ShopDataContext" xmlns="http://schemas.microsoft.com/linqtosql/dbml/2007">
  <Table Name="" Member="Customers">
    <Type Name="Customer">
      <Column Member="Name" Type="System.String" CanBeNull="false" />
      <Column Member="Address" Type="System.String" CanBeNull="false" />
      <Column Member="Phone" Type="System.String" CanBeNull="false" />
      <Column Member="ID" Type="System.Int32" IsPrimaryKey="true" CanBeNull="false" />
      <Association Name="Customers_Orders" Member="Orders" ThisKey="ID" OtherKey="CustomerID" Type="Order" />
    </Type>
  </Table>
  <Table Name="" Member="Orders">
    <Type Name="Order">
      <Column Member="Date" Type="System.String" CanBeNull="false" />
      <Column Member="ID" Type="System.Int32" IsPrimaryKey="true" CanBeNull="false" />
      <Column Member="CustomerID" Type="System.Int32" CanBeNull="false" />
      <Association Name="Orders_Orderdetails" Member="Orderdetails" ThisKey="ID" OtherKey="OrderID" Type="Orderdetail" />
      <Association Name="Customers_Orders" Member="Customer" ThisKey="CustomerID" OtherKey="ID" Type="Customer" IsForeignKey="true" />
    </Type>
  </Table>
  <Table Name="" Member="Orderdetails">
    <Type Name="Orderdetail">
      <Column Member="ID" Type="System.Int32" IsPrimaryKey="true" CanBeNull="false" />
      <Column Member="OrderID" Type="System.Int32" CanBeNull="false" />
      <Column Member="ArticleID" Type="System.Int32" CanBeNull="false" />
      <Association Name="Orders_Orderdetails" Member="Order" ThisKey="OrderID" OtherKey="ID" Type="Order" IsForeignKey="true" />
      <Association Name="Articles_Orderdetails" Member="Article" ThisKey="ArticleID" OtherKey="ID" Type="Article" IsForeignKey="true" />
    </Type>
  </Table>
  <Table Name="" Member="Articles">
    <Type Name="Article">
      <Column Member="Name" Type="System.String" CanBeNull="false" />
      <Column Member="Description" Type="System.String" CanBeNull="false" />
      <Column Member="ID" Type="System.Int32" IsPrimaryKey="true" CanBeNull="false" />
      <Association Name="Articles_Orderdetails" Member="Orderdetails" ThisKey="ID" OtherKey="ArticleID" Type="Orderdetail" />
    </Type>
  </Table>
</Database>

Unterscheidet sich das wesentlich von deinem Xml?

Das zugehörige DB-Layout sieht so aus, und das ist eine Ansicht, in der ich ein DB-Layout verstehen und entwerfen kann.

lazy loading:
man kann in nhibernate einzelne properties lazy stellen. das ist ein unterschied zu ganzen tabellen.

für nhybernate binnich zu knickerig

naja... es gibt noch andere 123123123 tausend or-mapper.

Den einzigen und fatalen Nachteil von LinqToSQL findich, dasses ohne SQL-Server nix tut. Ein typisiertes Dataset kannich mit WriteXml auf Platte schreiben, das ist bis zu ca. 10MB Datenbanken performanter und Ressourcenschondender als das SQL-Server-Monstrum.

ich habe mal mit dem or-mapper openaccess gearbeitet, der im übrigen auch mit xml arbeiten kann. zudem kann man uch z.b. sich zu einer datenbank connecten und seine objekte laden, dann diese offline serialisieren/deserialisieren und irgendwann alle änderungen wieder voll versioniert in die datenbank einspielen.

Datenklassen in Xml zu schreiben scheint mir umständlich.

in nhibernate kannst du bensogut eine datenbank designen und auf basis der datenbank ein xml-schema generieren lassen und auf dessen basis wiederum klassen generieren lasen... das geht bei nhibernate z.b. in alle richtungen.....

Besonders lustig: Man kann sich die SQL-Commands ausgeben lassen, die der an die DB absetzt.

das können die meisten or-mapper

@ErfinderDesRades:

1. NHIBERNATE IST KOSTENLOS.

2. ActiveWriter ist für NHibernate und/oder Activerecord, ginge aber aus der
   Doku hervor, aber wer liesst die schon.

3. ActiveRecord ist NHibernate on Steroids. Statt XML-Beschreibung
   vergibst du wie bei LinqToSql die verbindungen per Attribute.

Aber auch das könntest Du selbständig aus der Doku entnehmen.

(Wieso habich eigentlich immer das Gefühl, du hast was persönliches gegen mich?)

Und, Doku, also mein Englisch ist ziemlich mühsam, ich war auf http://altinoren.com/default.aspx , dann auf http://altinoren.com/activewriter/ ("Introduction"), dann noch Getting Started gelesen, und das Readme im Download.

Hinweise auf einen Zusammenhang mit ActiveRecords (da binnich auch gewesen, das schien mir aber ein Ruby-Teil zu sein) und nhybernate habich zwar wahrgenommen, aber sowas eindeutiges wie "Precondition to work with..." oder "First set up..." ist nicht in den Texten, die ich gefunden habe. Habich irgendwelche Doku übersehen?

Jedenfalls Danke für die Info.

Habich irgendwelche Doku übersehen?

Defintiv:
Für NHibernate z.b.:
http://blogs.hibernatingrhinos.com/nhibernate/archive/2008/03/31/prepare-your-system-for-nhibernate.aspx
http://blogs.hibernatingrhinos.com/nhibernate/archive/2008/04/01/your-first-nhibernate-based-application.aspx

ActiveRecord:
http://www.castleproject.org/activerecord/gettingstarted/index.html
http://www.castleproject.org/activerecord/gettingstarted/requirements.html

Btw: was ist nhybernate?

Hallo regen,

was ist nhybernate?

ein Tippfehler 🙂

herbivore

ein Tippfehler 🙂

dachte ich auch, zumindest beim ersten Post

Hallo,

ohne jegliche Designer würde ich überleben. Ich habe das Zeug irgendwie immer von Hand gemacht (ausser WindowsForms) und dann habe ich Erfahren dass es Designer für typed DataSets und O/R-Mapper gibt.

Aber ohne IntelliSense und Objektbrowser würde meine Produktivität glaube ich um 50% fallen. Ich kann mir einfach nicht mehr Vorstellen so nebenbei die Doku offen zu haben und danach zu programmieren.

Und wenn es einen Leichtgewichtigeren Editor geben würde, der IntelliSense/MSDN genauso unterstützt wie Visual Studio würde ich VS in die Tonne kloppen.

Gruss
tscherno

Aber ohne IntelliSense und Objektbrowser würde meine Produktivität glaube ich um 50% fallen. Ich kann mir einfach nicht mehr Vorstellen so nebenbei die Doku offen zu haben und danach zu programmieren.

ich muss leider eingestehen, das meine produktivität ohne resharper um etwa 70% sinken würde (zumindest den ersten monat..) aber designer... brauche ich eigendlich nicht.

Hallo tscherno,

Aber ohne IntelliSense und Objektbrowser würde meine Produktivität glaube ich um 50% fallen. Ich kann mir einfach nicht mehr Vorstellen so nebenbei die Doku offen zu haben und danach zu programmieren.

vielleicht stimmt das bei dir, im Allgemeinen stimmt das glaube ich nicht. Zumindest lese ich hier im Forum viele Fragen, die mit einem Blick in die Doku leicht hätten geklärt werden könnten. Ich erkläre mir das so: Die Methoden (und natürlich alle anderen Member) werden nur anhand von Intellisense ausgewählt, ohne in der Doku nach deren Rahmenbedigungen und Hinweisen zur Benutzung zu schauen. Welche Exceptions werden geworfen? Welche Voraussetzungen müssen vor dem Aufruf geschaffen sein? Welche Bedingungen werden an die Parameter gestellt? Wie sind die Rückgabewerte zu interpretieren. Soweit ich weiß, zeigt Intellisense das alles nicht an, sondern man sieht es nur, wenn man die Doku öffnet. Was mal also beim Tippen spart, zahlt man beim Test doppelt oder dreifach wieder drauf.

Natürlich kann man die Doku dank Intellisense leicht an der richtigen Stelle öffnen. Aber danach klang dein Lob in meinen Ohren nicht.

Um das Ganze noch zu konkretisieren: Es wird z.B. sehr oft fälschlich die Focus-Methode verwendet, obwohl im der Doku steht:

Focus ist eine Methode auf niedriger Ebene, die hauptsächlich für Autoren benutzerdefinierter Steuerelemente bestimmt ist. Anwendungsprogrammierer sollten hingegen die Select-Methode oder die ActiveControl-Eigenschaft für untergeordnete Steuerelemente bzw. die Activate-Methode für Formulare verwenden.

Und dann kommt hier die Frage, warum der Focus-Wechsel nicht klappt. Hätte man gleich die ActiveControl-Eigenschaft verwendet, hätte man sich diesen (Test- und Korrektur-)Aufwand gespart.

herbivore

Ich kann nur bestätigen was Herbivore über Intellisense sagt, Intellisense verwöhnt einen zusehr und programmieren wird schnell zum zusammenklicken der einzelnen Bestandteile. Wenn man mal geswungen wird, ein Programm in egal welcher Programmiersprache ohne IDE zu schreiben, stößt man dort schnell an seine Grenzen.

Doku der Programmiersprache nebensich liegen zu haben, ist aber in vielen Sprachen nicht möglich und auch ineffizent. Google ist das beste Nachschlagewerk. Weiterhin, der Objektbrowser ist völlig überflüssig. In Google Klassenname + Member eingegeben kommt man spätestens mit den 3 Treffer auf die Microsoft MSDN Seite, wo nicht nur die Funktionen selbst und ihre Erklärungen stehen, sondern auch meistens Beispiele und Was-Ist-Zu-Beachten

Google ist das beste Nachschlagewerk. Weiterhin, der Objektbrowser ist völlig überflüssig. In Google Klassenname + Member eingegeben kommt man spätestens mit den 3 Treffer auf die Microsoft MSDN Seite, wo nicht nur die Funktionen selbst und ihre Erklärungen stehen, sondern auch meistens Beispiele und Was-Ist-Zu-Beachten

Dem kann ich zu 100% zustimmen.

Ich habe im Hintergrund immer ein IExplorer mit Google offen. Google + MSDN (+ hier natürlich) ist die beste Doku die es gibt. Und Stichwörter/Suchbegriffe gebe ich immer in englisch an! Die Trefferquote dürfte so 50% höher liegen, als gegenüber den deutschen Begriffen.

Anzumerken ist auch, das IntelliSense nicht alles anzeigt. Man kann auch Methoden vor IntelliSense verstecken.

Hi,

Also ich würde IntelliSense nicht zu sehr beschimpfen.

1. Zeigt es schon einiges an Informationen an: <summary>-Block der Methode, <exception>-Blöcke der Methode und <summary>-Blöcke der Parameter.
2. Macht es (zumindes mich) Wahnsinig, jede Methode auszuschreiben.

Wenn man mit neuen Objekten/Klassen arbeitet, reicht das meistens nicht aus und man muss sowieso in die Doku schauen. Aber bei bekannten Objekten/Klassen ist IntelliSense genau die richtige Menge Information.

Gruß
Juy Juka

@ErfinderDesRades:
Dann solltest Du dringend an deinem englisch arbeiten, dann wie willst du dich sonst wirklich zurechtfinden.