Technologievielfalt im Framework - Fluch oder Segen?

Hallo zusammen,

das .Net Framework bietet mit unzähligen Klassenbibliotheken mittlerweile die vielfälltigsten Möglichkeiten Probleme zu lösen: Windows Forms, WPF, Silverlight, WCF, WF, WIF, ASP.NET MVC um einfach mal beispielhaft ein paar Technologien querbeet zu nennen.

Fühlt ihr euch durch diese Technologien eingeschränkt und habt das Gefühl, dass ihr sie kennen müsst oder seht ihr sie eher als Möglichkeiten Probleme effektiv mit etablierten Frameworks zu lösen und sie je nach Bedarf einsetzen zu können?

Hallo talla,

es ist schon machmal blöd, wenn man irgend etwas selber macht und dann nachher merkt, ach, da gab es ja doch was im Framework für. Und rechtzeitig herauszufinden, dass es da schon was gibt, wird natürlich immer schwieriger, je größer der Umfang wird. In diesem Sinne steigt die Unübersichtlichkeit schon. Und das wird auch nicht gerade einfacher dadurch, dass gleichzeitig bestimmte Methode, Klasse, Namespaces oder ganze Bereiche mehr oder weniger obsolet werden (ArrayList vs. List<T>, DataGrid vs. DataGridView). Aber im allgemeinen betrachte ich das schon positiv als Angebot, aus dem man wählen kann, ohne alles (vorher) kennen zu müssen.

herbivore

Hallo talla,

ich sehe es ähnlich wie herbivore.
Insbesondere sehe ich es als Vorteil auf etablierte und fehlerfreie* Klassen zurückgreifen zu können. Dies schätzte ich v.a. deshalb, da ich von einer Programmiersprache komme die von Haus aus nicht viel dabei hat (Fortran) und dort gewisse "Standard-Dinge" entweder selbst implementiert werden mussten od. irgendwo extern bezogen werden mussten.

Um das Richtige aus dem großen Angebot auszuwählen gilt hier wohl auch "wer die Wahl hat, hat die Qual".

mfG Gü

* sollte eine Klasse fehlerhaft sein, so fällt das i.d.R. aufgrund der großen Benutzerzahl auf und kann gefixt werden. Daher kann davon ausgegangen werden, dass die Zahl der Bugs im Framework sinken wird.

Eigentlich finde ich eine Stärke von Frameworks ist, dass es gut entwickelte Technologien für bestimmte Bereiche gibt und man diese (in der Regel) gut verwenden kann.

Hingegen müsste man sich ohne "übergeordnetes" Framework oftmals erstmal einige Zeit damit beschäftigen, welche Bibliotheken es denn z.B. für grafische Anwendungen, usw. für eine bestimmte Sprache gibt und welche aktuell am "sinnvollsten" ist. Dazu kommt dann noch, dass entsprechende IDE dann eben auch nicht unbedingt gute Unterstützung bieten.

Wobei ich bezogen auf's .NET Framework da herbivore schon zustimmen muss. Zumindest bezogen auf GUIs finde ich die Auswahl zwischen WinForms und WPF vernünftig... nicht zu viel, nicht zu wenig, beide mittlerweile recht brauchbar unterstützt (da halt auch offiziell) und mit genug Unterschieden. Wobei ich bei WPF etwas das Gefühl habe, dass sich Microsoft doch sehr auf der Mächtigkeit ausruht, was IMO halt allgemein auch eine Gefahr bzw. Unschönheit ist.

Eine dritte große UI-Technologie muss ich aber nicht unbedingt haben. An manchen Stellen würde ich mir aber auch mehr Auswahl direkt im Framework wünschen, gerade in Hinblick auf gängige Standards. Dass z.B. XPath 2.0 respektive XSLT 2.0 immernoch nicht unterstützt wird, finde ich naja recht "unschön".

Ich habe vor 24 Jahren mit Basic angefangen und dann mit Assembler weitergearbeitet. Wenn ich daran zurück denke wie problematisch es damals war, freue ich mich über die heutige Vielfalt. Einfachste Dinge hatten plötzlich unzählige Zeilen an Code. Was heute mit einer Zeile oder einem Klick bewerkstelligt wird, ergab damals hunderte von Zeilen.

Vielleicht ist der Unterschied aufgrund der Zeit sehr krass, aber heute kann man sich dadurch mehr auf das Entwickeln selbst beschäftigen, anstatt den kram drumrum zu bauen.

Hallo talla,

ich persönlich sehe das aus zwei "Perspektiven":

Unter .NET habe ich schon einiges an Erfahrung mit den verschiedensten Technologien gesammelt: WinForms / WPF, ASP.NET / ASP.NET MVC, Remoting / WCF, ADO.NET / LINQ to SQL / EF...
Durch die Anwendung der Technologien entwickelt man mit der Zeit ein Gefühl, welche Technologie in welcher Situation die "Richtige" ist bzw. welche Vorteile auch jenseits des Marketing-Papers spürbar sind (und über welche erheblichen Nachteile niemand spricht).
Hier ist die Technologievielfalt folglich eher "Segen" für mich: Ich kann die Vorteile aller Technologien nutzen, indem ich jeweils die "richtige" wähle; dabei verwende ich manche Technologien (für neue Projekte) überhaupt nicht (bspw. kalssisches ASP.NET), während ich bei anderen Technologien keine generellen Präferenzen habe (wie WinForms / WPF).

Allerdings: Zum "Segen" ist die Technologiefülle für mich nur durch die Erfahrung geworden, die ich (hauptsächlich neben meiner Schulzeit) selbst mit den Technologien gemacht habe.
Hätte ich diese Zeit für "sinnlose" Projekte (aus Sicht der Sinnhaftigkeit, Vollständigkeit etc. - aus den meisten ist nichts wirklich Brauchbares für ohnehin nicht existierende Anwender geworden) allerdings nicht gehabt, und wäre alleine auf Dokumentation und Artikel angewiesen gewesen, glaube ich nicht, dass dieser Zustand jemals eingetreten wäre.

Sehr extrem merke ich das derzeit bei Java: Hier fehlt mir bisher noch einiges an praktischer Erfahrung, die ich auch in nächster Zeit nicht in dieser "ungezwungenen" Form sammeln kann, wie mir das unter C# / .NET möglich war.
Hierzu fehlt mir inzwischen einfach die Zeit; wenn etwas in Java entwickle, muss am Ende auch ein Endprodukt stehen, bei dem "technologische Perfektion" eine sehr untergeordnete Rolle spielt.

Das führt dann bei mir im Moment dazu, dass ich vermutlich unter Java häufig suboptimale Lösungen einsetze, über deren .NET Äquivalent ich genau wüsste, dass es eine bessere Technologie gäbe.

Unter .NET käme ich z.B. nie auf die Idee, mit einem XmlReader ein XML-Dokument zu parsen.
Unter Java? Da mir die Zeit für eine intensive Recherche / Vergleich von XML-Parsing unter Java schlichtweg nicht zur Verfügung stand / steht, parse ich dort ein Dokument gerade mit XPath-Klassen.
Ob es bessere Möglichkeiten gäbe? Sicherlich - aber ich habe mich selbst dabei ertappt, wie ich einfach die "Erstbeste" Technologie genommen habe.
Den Versuch, mittels Java eine dynamische Webseite zu erstellen, habe ich sogar wieder zurückgestellt: Einfach zu groß ist die Fülle der techologischen Möglichkeiten und Varianten und die Aussagen über Vor- und Nachteile davon sind widersprüchlich und helfen nicht wirklich. Um eine Vielzahl kleiner Beispielprojekte käme ic folglich nicht herum - und selbst dann müsste ich erst einmal herausfinden, welche Möglichkeiten es überhaupt gibt (und nicht nur, welche besonders häufig diskutiert werden, da es sie schon lange gibt).

Insbesondere den Einstieg in eine derartige Technologievielfalt halte ich somit für sehr problematisch: Woher soll man als Anfänger wissen, dass eine Technologie inzwischen obsolet ist, wenn diese noch Top-Plätze im Google-Suchranking einnimmt?
Wie soll man erfahren, dass eine andere Technologie weitaus besser geeignet wäre, als die erstbeste, mit der es auch irgendwie funktioniert?
Wie unterscheidet man "Marketing-Geschwätz" von echten Ratschlägen?

Unter .NET muss ich inzwischen wohl sogar ehrlich zugeben, dass ich eine gewisse "Technologiearroganz" entwickelt habe:

Ich werfe es Fragestellern vor, wenn sie in der WPF Controls statt via DataTemplates über Schleifen erstellen, LINQ to Objects mit dem EF verwechseln, oder sich über die Performanceunterschiede von Properties und Feldern auslassen.

Aber wirklich anders würde es mir wohl als Einsteiger auch nicht gehen bzw. geht es mir unter Java auch nicht.
Klar - Informationen findet man überall:

Aber wie soll ich bewispielsweise ohne dieses Praxiswissen erkennen, dass die in unzähligen Blogposts und Diskussionen thematisierten Performanceunterschiede zwischen Feldern / Properties für mich nicht relevant sind?
Oder einsehen, dass die unzähligen WPF-Beispiele von "Pseudo-Experten", die hunderte Zeilen von Code schreiben, um den "WPF-Designfehler" zu "beheben", dass man nicht ohne Weiteres auf die generierten Controls eines ItemControls zugreifen kann, auf unzureichenden Erfahrungen basieren?
Welche Chancen habe ich, wenn mit "LINQ" mal "LINQ to Objects", mal "LINQ to SQL", mal "LINQ to Entities / EF" gemeint und dann mal wieder die Gesamtheit aller Technologien mit LINQ im Namen gemeint ist?

Vielelicht ist auch vielmehr das Problem, dass man viel zu leichtfertig annimmt, man beherrsche eine bestimmte Technologie, wenn man eigentlich gerade mal einen Bruchteil davon begriffen hat.
Schnelle Ergebnisse erreicht man in der Softwareentwicklung bekannterweise durchaus recht problemlos; aber für qualitative Ergebnisse kommt man eben nicht um einen gewissen Aufwand herum.

Leider wird heutzutage hauptsächlich vermittelt, wie einfach Softwareentwicklung doch ist und dass quasi jeder nach ein paar Wochen Trainings jede Art von Anwendung entwicklen kann.
Und Ausbildung beschränkt sich meist auf Sprachsyntax und "die eine" Technologie, die man dann (in Projekten, Klausren etc.) einsetzen zu hat.
Wo bleibt da dann der Blick "über den Tellerrand", um beispielsweise zu erkennen, dass Datenbankzugriff unter C# eben nicht automatisch ADO.NET bedeutet, sondern auch NHibernate oder das EF eine deutlich bessere Alternative darstellen können?

Insofern ist die Technologievielfalt im Framework für die meisten (insbesondere Einsteiger) vermutlich ein Fluch; es fehlt einfach an geeigneten Überblicken bzw. an der Zugänglichkeit derselbigen.
Nur durch einen enormen Zeitaufwand schafft man es dann nach und nach, dass für einen selbst der Fluch nach und nach zum Segen wird.
Doch dafür hat man in den meisten Fällen vor dem Hintergrund der erwarteten, schnellen Ergebnisse wohl nicht die nötige Zeit.

Technologievielfalt im Framework für mich? (Derzeit) ganz klar Segen - aber ich habe vollstes Verständnis für diejenigen, die sie als Fluch ansehen.
Unter Java erlebe ich nämlich derzeit genau dieses Gefühl.

Hallo,

Aber wirklich anders würde es mir wohl als Einsteiger auch nicht gehen bzw. geht es mir unter Java auch nicht.
Klar - Informationen findet man überall

Das empfand ich sogar als großes Problem - es gibt im Grunde zu viele Informationen, abertausende Tutorials. Und leider veralten diese zu schnell.
Als wir mit .Net anfingen, existierte .Net 2.0 schon für eine gewisse Zeit (~1 Jahr). Es gab aber, bspw., jede Menge Tutorials oder Blogs, die zeigten, wie man XML parst und dafür .Net 1.1 Mittel verwendet haben, weil das zur Zeit der Erstellung aktuell war. Die Einordnung ohne vernünftige Übersichten fiel sehr schwer und verursachte gewisse Unsicherheiten.
Ein anderes Beispiel ist die Entwicklung von WPF aus Avalon - viele Informationen waren aufgrund geänderter API (und wenn es nur der XML Namespace war) schon beim Release von .Net 3 einfach veraltet.
So entsteht aus dem Vorteil der Dynamik der Entwicklung tatsächlich ein Nachteil.

Ein anderer Punkt ist die Dokumentation. Zum großen Teil werden auch in Büchern bei Neuauflagen viele Altlasten mitgeschleppt. Die MSDN ist zwar ein sehr gutes Referenzwerk - aber dazu muss man ja wenigstens die Klasse kennen. Oder Namespaces raten. Da sich aber etwa eine BindingList unter System.ComponentModel und nicht unter System.Collections befindet, ist das eine sehr unsichere Methode.
Eine richtige Framework-Referenz (gedruckt) gab es wohl zuletzt unter .Net 2.0 (in 6-7 Bänden). Wie umfassend die tatsächlich war, kann ich nicht sagen. Jedenfalls habe ich aber kein Buch gefunden, das wirklich "alles" behandelt hat - von P/Invoke, über COM bis Remoting. Und nein - jetzt brauch' ich es nicht mehr...

Die Technologievielfalt empfinde ich meistens als Segen.
Ich arbeite intensiv mit WCF, WIF und ASP.net. Das Arbeiten ist effizient, da das Framework extrem viel bietet.

Sehr unzufrieden bin ich mit den "halbfertigen" Teilen von Microsoft wie Beispielsweise Windows WF oder AppFabric.
Wieso soll ich mir die Mühe machen diese Technologien auch nur anzufassen?

Als "Programmier-Framework" ist .NET auf jeden Fall sehr gut.

Was ist am Reporting Service halb fertig?

Ich sehe die Vielfahlt das im Großen und Ganzen sehr positiv; bin dennoch der Meinung, dass einige Stellen wirklich noch Baustellen oder zumindest Verbesserungswürdig sind.

Beispiele:

* Namespace System.IO

• Unterstützung von UNC-Pfaden mit 32767 Zeichen nicht vorhanden
• Sehr unperformant (im Gegensatz zu Shell und FindFile)

* Windows Workflow Foundation

• Parallel Tasks werden nicht parallel ausgeführt; dazu gibt es aber schon genug Reports an MS

* ASP.NET MVC

• Bugs im ModelBinder seit MVC 2

* Entity Framework (4.1)

• Maximale Entitylänge von 19 Zeichen bei der Verwendung von Proxies

Um auf gfoidls Einwand noch im Nachhinein einzugehen:
Damit will ich ausdrücken, dass man sich unter umständen sehr von einer Technologie abhängig machen kann, die zu späterem Zeitpunkt überhaupt nicht mehr gewartet oder weiterentwickelt wird.
Zu viel Vielfalt sprengt dann auch den Rahmen, den Microsoft mit dem Beheben von Fehlern einfach nicht mehr einhalten kann. Daher finde ich meine Auflistung durchaus als angebracht.

Die Vielfalt alleine ist einfach kein Segen, wenn sie unter solchen Grundlagenfehlern leidet oder diese nur halblebig (wie ich das im Falle von WF empfinde) umgesetzt wird.

Ach, da gibt es einiges... z.B. das spärliche Berechtigunsmodell (in zusamenarbeit mit MOSS), den Report Builder 3 (Keine DAX oder WIF Unterstützung, Query-Design via SOAP nicht möglich), das fallen lassen von Report Models OHNE Ersatz (!!!)...

Als Segen empfinde ich die Entwicklungsumgebung/IDE.
Es ist enorm hilfreich die verschiedenen FW-Versionen und Technologien mit dem gleichen Tool zu erstellen.