Nutzen Drittanbieter-Komponenten (z.B. DevExpress) mehr als sie kosten (an Einarbeitungsaufwand)?

Hallo zusammen,

ich arbeite gerade an einem Projekt, wo wir 3 Anbieter Komponenten
wie z.B. DevExpress in die Anwendungen integrieren.

Wie ist eure Erfahrung damit? Ich muss sagen, die können zwar ne Menge, aber
auf der anderen Seite braucht man ja für jedes Control ne Anwenderschulung.

Ich frage mich, ob diese Komponenten wirklich die Entwicklungszeit verringern oder durch den Overhead an "Features" nicht allzuoft die Entwicklungszeit erhöhen?
So ein Controll muss ja auch erst einmal "verstanden" werden, zumal die methoden und Events sich teils erheblich von denen normaler VS komponenten unterscheiden.

Wir arbeiten gerade mit einer XTreeList von DevExppress.
Was kann das Ding denn nun mehr als ein normaler TreeView ?

Würde mal gerne eure Erfahrungswerte zu 3 Anbietern hören...

Hallo wickedcsharper,

nutzt das .NET-Framework mehr als es an Einarbeitungsaufwand kostet? Im Grunde stellt sich diese Frage bei jeder Bibliothek. Und die Antwort hängt davon ab, ob man dass, was die Bibliothek bietet, auch benötigt, bzw. in welchem Umfang man das tut. Bei GUI-Bibliotheken kommt noch dazu, dass die Vorteile zum Teil beim Benutzer liegen, der (Einarbeitungs-)Aufwand aber beim Entwickler.

Natürlich sprich nichts dagegen, dass Erfahrungsberichte gepostet werden. Nur ist die Antwort auf die Frage höchst individuell, weil es eben nicht nur von der Bibliothek abhängt, sondern eben auch davon, was man daraus braucht. Und das ist höchst individuell. Das wollte ich damit sagen.

herbivore

Hi,

wir haben das jetzt schon seit ca. 4 Jahren im Einsatz und sind relativ zufrieden damit.

Schau dir doch mal die Demos an, die mit dem Setup mit installiert werden. Da sind alle Features mit relativ guten Beispielen beschrieben.

Einarbeitungszeit ist m. E. nicht einmal so hoch. Man muss halt mal mit den meisten Flags usw. rumgespielt haben, damit man sieht, was sie bewirken und was man denn genau haben möchte. Vorteile gegenüber dem Standard von WinForms gibts eine ganze Menge, aber dazu guckst du dir am besten die Demos an.

Gruß
Roland

Der Mehraufwand lohnt sich, im speziellen wenn man DevExpress nutzt. Z.B. Das Grid-Control von DE im Vergleich mit dem Standard, das sind Welten.

Wir nutzen DevExpress schon länger und sehr zufrieden und wollen es auch nicht mehr missen.

So, genug Werbung gemacht. 😃

Wobei man sich gerade bei DX manchmal fragt, was die sich gedacht haben.

Schonmal das XTreeList aus einem Thread mit Daten versorgen müssen?
Wir haben einen Tree der je nach DB Umfang schon mal grösser und tiefer werden kann.
Beim normalen Tree wird dann einfach der Nodestree im Thread erstellt und befüllt, und dann im GuiTread am ende übergeben und angezeigt.
Beim XTreeList kann man elemente nur im UIThread hinzufügen, denn für die Nodes gibt es keinen öffentlichen Constructor, und somit muss man jeden Node einzeln per Invoke vom TreeList erzeugen lassen.
Macht dann das Threading nicht wirklich sinnvoll.

Oder setze mal einen Button in ein Dockpanel das in einem DockPanel steckt.
Jetzt gibt es kein Hovereffekt mehr.

So gibt es haufenweise Stolpersteine, die im Endeffekt dazu geführt haben das unsere nächste SW keine DX Controlls mehr haben wird.

@FZelle
Das XtraTreeList unterstützt Databinding. Eventuell könntest Du ja ein z.B. DataTable in Deinem Thread laden und dann dieses an das Control binden, statt die Nodes direkt zu erzeugen.

@wichedcsharper
Ich nutze DevExpress seit einiegn Jahren. Aus meiner Sicht lohnt sich der Einarbeitungsaufwand allemal (aber bitte nicht mit einer Schulung - die könnte entweder nur sehr oberflächlich auf die Möglichkeiten eingehen oder würde etliche Wochen dauer - besser learning by doing. Man braucht ja nicht von anfang an sämtliche Features). Schau Dir die Demos an (wurde ja schon vorgeschlagen) um Anregungen zu bekommen und dann leg einfach mal los - ist alles halb so wild... Belohnt wirst Du mit Komponenten, die alles was ich so bisher gesehen habe (und das sind alle bekannten GUI Komponenten der größeren Hersteller wie Telerik, Infragistics, Componentone etc.) quantitativ und vor allem qualitativ in den Schatten stellen. Richtig ist aber auch was FZelle sagte, bei DevExpress funktioniert manches ein wenig 'anders' als das was man so standardmässig kennt...

Hallo,

ich verwende jetzt speziell zwar nicht DevExpress aber Telerik.
Und ich muss auch sagen dass es den Aufwand auf jedem Fall wert ist.
Sofern man die Controls wirklich benötigt. Wenn man nur die Standard Funktionen verwendet die die dot.net controls schon können dann macht es eher wenig Sinn.

Aber wenn man irgendwelche erweiterten Dinge braucht die nur diese Controls können, so erspart man sich sehr viel Arbeit.
Und der Aufwand sich in so ein Control einzuarbeiten ist in meinem Fall mit Telerik nicht so hoch gewesen.
Es gibt richt viele Beispiele, somit war es ein Leichtes die Controls richtig zu verwenden.

Also meiner Meinung sind es die Controls Wert, sofern man Funktionen benötigt die noch nicht in den standard Controls sind

Grüße
Michael

Man muss bei der Fragestellung auch gucken, um was für Controls es geht. Wir verwenden Fremdanbieterkomponenten (nur) an den Stellen, wo es nichts passendes bzw. mit vertretbarem Aufwand anpassbares aus dem .NET-Framwork gibt.
So z.B. das UltraGrid von Infragistics (hierarchisches DataGrid) oder das PivotGridControl (plus Integration der Charting-Komponente) von DevExpress. Solche Komponenten bekommt man selbst nicht so schnell selbst implementiert - und die Ausgereiftheit ist auch je nach Fremdhersteller stark schwankend. Die Hersteller haben zwar auch simple Controls (Textboxen, Comboboxen, ...) im Angebot - allerdings braucht man viele Features überhaupt nicht. Also werden sie auch nicht benutzt (wodurch dann auch der Einarbeitungsaufwand wegfällt).

Zum Thema Overhead: Wer hier über DevExpress meckert, hat wohl noch nie mit Infragistics-Komponenten gearbeitet 😃 Bei den Controls, die mir bisher untergekommen sind, waren die von DX fast simpel. Bei den IG-Controls kann man alles mögliche Anpassen - was allerdings dazu führt, dass man einfache Aufgaben erstmal das korrekte Property ausgraben und den korrekten Zeitpunkt zum Setzen finden muss.

Warum das Rad neu erfinden, wenn es das schon gibt.

Ganz gleich um welche Komponenten Library Drittanbieter es geht, der Faktor Zeit in Sachen Einarbeitung steht in keinem Verhältnis zu dem Zeit- und Frustfaktor etwas nicht im Standard vorhandes selbst umzusetzen.

Zumindest bei der Umsetzung einer kommerziellen Applikation gibt es für mich keine Alternative.