Willkommen auf myCSharp.de! Anmelden | kostenlos registrieren
 | Suche | FAQ

Hauptmenü
myCSharp.de
» Startseite
» Forum
» Suche
» Regeln
» Wie poste ich richtig?

Mitglieder
» Liste / Suche
» Wer ist online?

Ressourcen
» FAQ
» Artikel
» C#-Snippets
» Jobbörse
» Microsoft Docs

Team
» Kontakt
» Cookies
» Spenden
» Datenschutz
» Impressum

EBCs 2.0, deren Nähe zur prozeduralen Programmierung und deren Nutzen [inkl. Metadiskussion]
malignate
myCSharp.de - Member

Avatar #avatar-3206.png


Dabei seit:
Beiträge: 742

beantworten | zitieren | melden

Ich weiß zwar ehrlich gesagt nicht mehr um was es in der Diskussion ging, aber ich schließe mich Uwe81 aber an.

Ich hatte bisher in meinen noch nicht ausreichenden Experimenten die Erfahrung gemacht, dass sich Abhängigkeiten nicht eliminieren lassen. Eine logische Abhängigkeit zu entfernen ist sehr schwer, bis gar unmöglich, je nachdem wie das Problem gestaltet ist.

Mein Code durch EBCs hat sich dabei so verändert, dass die Abhängigkeiten von den Komponenten weg, in die Platinen gewandert ist. Das ist ja ganz nett, weil ich die Komponenten leicht testen kann, aber die Komponenten haben sich zu einem Chaos entwickelt.

Viele meiner Komponenten hatten bisher lineare Abhängigkeiten:

A -> B -> C -> D -> ... (A verwendet B, B verwendet C, ...), mit EBCs hat sich das in eine Hierarchie geändert:

P1 -> A, B, C; P2 -> D, E, F; P3 -> P1, P2 (Platine P1 verwendet A,B und C, Platine P2 verwendet D, E, F, ...):

Das heisst meine Abhängigkeiten hatten sich nur verändert und wurden nicht weniger.

Toll fande ich zu Beginn auch die Möglichkeit mich in den Programmablauf zu hängen und z.B. zu Loggen oder Proxies zu schreiben. Das geht zwar auf so elementare Weise in normalem Code nicht, aber ich sehe jetzt keinen Nachteil Interface Proxies (wie in Mockup Frameworks) oder AOP Frameworks verwenden zu müssen. Insofern bringen mir hier EBC keine neuen Features, vll. bisschen einfacher zu verwenden, aber auch die PostSharp Entwickler machne eine super arbeit).

Insofern muss ich sagen, dass auf Begeisterung Ernüchterung folgte, aber ich habe mich natürlich nicht wie du, Ralf, im Detail damit beschäftigt.
private Nachricht | Beiträge des Benutzers
Arithmetika
myCSharp.de - Member



Dabei seit:
Beiträge: 69

beantworten | zitieren | melden

Zitat
Wenn ein Prozessschritt auf den Erfolg zweier anderer warten muss, dann ist das mit IBC und EBC gleich.

Das ist vollkommen richtig. Jedoch habe ich etwas anderes behauptet. Ich meinte, das die Komponente oder der besagte Prozessschritt anders reagieren soll, wenn die jeweiligen Vorbedingungen in bestimmten Konstellationen erfolgreich oder nciht erfolgreich waren.

Das sind so die typischen kaufmännischen Abläufe.
Zitat
Was soll ich dazu sagen, Arithmetika?

Ich habe dich nicht direkt angesprochen. Daher habe ich auch keine Reaktion erwartet. Ich habe meine Meinung kundgetan und begründet, warum ich diese Meinung habe.
Zitat
Dass auch EBC wieder keine silver bullet ist? Klar. Habe nie das Gegenteil behauptet. Dass EBC OOP und IBC nicht überflüssig machen? Klar. Habe es nie anders gesagt.
ACK. Habe ich auch nicht behauptet.

Meine Kernaussage ist: Wenn man wirklich gut und Produktiv sein will, dann muss man sich auf einen etablierten Standard konzentrieren und darin möglichst Perfekt werden. Kein Projekt der Welt kann es sich leisten, vor der ersten produktiven Zeile Code alle Entwickler auf eine Schulung zu schicken und erstmal ein oder zwei mittlere Lernprojekte durchzuführen, um nachher eine relativ saubere Lösung zu haben.

Daher wird das mit EBC nichts (in meinen Augen), weil man nicht garantieren kann, das jeder (oder fast jeder) auch wirklich weiß was das ist und wenn auch nur einer nix damit anfangen kann, dann kommt dabei nur murks raus. Das ist schon häufig genug bei OOP so und dabei wissen glücklicherweise schon die meisten (hat ja auch sehr lange gedauert), was OOP ist.
private Nachricht | Beiträge des Benutzers
zommi
myCSharp.de - Member

Avatar #avatar-2617.png


Dabei seit:
Beiträge: 1.361
Herkunft: Berlin

beantworten | zitieren | melden

@Meta-Diskussion:
Hach, ich liebe Meta-Diskussionen. Aber leider bringen sie selten etwas. Bei Diskussion zu einem fachlichen Thema kann man Vor- und Nachteile objektiv darlegen. Hingegen ist eine solche Meta-Diskussion höchst subjektiv. Und so gibt es wohl immer komplementäre Meinungen. Wie hier auch. Achso und die Rolle des Vermittler gibt es natürlich auch stets, die eine entbrannte Diskussion etwas abkühlen wollen. Wie immer - alles hier vertreten :-) Die Standpunkte werden immer extremer, die Diskussion immer "unsachlicher" zugunsten ausgefeilter Dialektik - das hat zwar auch seinen Reiz - sowohl für Schreiber als auch für Leser. Aber wieso oft, finden die Gesprächspartner doch nie eine gemeinsame Synthese. Und im Gegensatz zu einem Streitgespräch im Fernsehen gibt es hier leider keine zeitliche Obergrenze. Daher zieht sich das online immer unangemessen in die Länge. Nunjaaa, aber am besten hat mir Ralfs "Sonst werd ich noch zynisch" gefallen. Aber ich nehm seine Forums-Watsche nicht so ernst, keine Sorge. Aber nun zurück zur "fachlichen", meines Erachtens weitaus interessanteren Diskussion.

@Eigentliche Diskussion:
Zuerst muss ich sagen, dass ich ein unwissender Student bin. Mein Erfahrungsschatz ist arg begrenzt. So habe ich nie ernsthaft etwas anderes als objektorientiert programmiert. Natürlich mit BASIC, Pascal, PHP <4, ASM und auch Sprachen wie Lisp, Haskell, Prolog, ... aber über LinesOfCode im 3-stelligen Bereich kam ich dort nie hinaus. (ich nehm LOC jetzt einfach mal als Maß für die Komplexität) Also was ich gut kenne ist OOP, den Rest nur vom Spielen und Hören-Sagen. Was sich manche für OOP also erst erarbeiten mussten, habe ich sozusagen mit der IT-Muttermilch aufgesogen - im Gegensatz dazu ist aber meine Erfahrung eingeschränkt. Aber vielleicht kann ich trotzdem dazu etwas sagen.

Und ich muss sagen EBC find ich vom Motiv gut. (Sowieso begeistern mich als Jungspund neue Techniken immer: *heyyy begeisterung!!!* ) Zwar habe ich noch keine "dicken Business-Anwendungen" geschrieben, aber über Programmiertechniken kann ich ja trotzdem schwadronieren.

Warum find ich das gut? Ich mag diese Datenfluss/Event - basierten/orientierten Konzepte. Programme wie
Generic Manipulator Tool
QuartzComposer
oder ein Programm, dass wir auf Arbeit verwenden, finde ich ausgesprochen gelungen. Die Idee "visuell" zu "programmieren" gefällt mir einfach. Ich sitz ja auch seit einiger Zeit hobbymäßig daran, so etwas umzusetzen. (Auch wenn das "Programmieren ohne Programmieren" nicht jedem gefällt: Programme erstellen ohne Programmierkenntnisse wie steht ihr dazu??? )
Allerdings muss meiner Meinung nach das Programmierkonzept sich auch ändern! Für alle imperativen Sruktur-Elemente wie If/While/For einfach kleine Grafiken einzufügen und somit nur den sequentiellen Kontrollfluss darzustellen ist keine Leistung. Dann sind wir beim AppInventor, der auch nur glossy, bunte Nassi-Shneiderman-Diagramme abbildet.

Wenn man hingegen "richtig" graphisch programmiert, stellt man wohl auf abstrakter Ebene irgendwie "Funktionseinheiten" als Kästchen/Kreise/Knubbel dar. Und deren Interaktion durch Linien. Im Grunde läuft es immer auf einen Graphen hinaus. Und wenn dieser Graph gerichtet ist, liegt das Datenfluss-Konzept schon sehr nah.

Und ich muss sagen, dass mich EBC stark an dieses Fluss-Konzept erinnert. Besonders EBC 2. Zwar spricht ralf ja konkret von Prozessen und weniger von Daten. Aber die beiden Begriffe ergeben ja erst zusammen ein einheitliches Bild. Prozesse verarbeiten Daten - Daten werden in Prozessen verarbeitet. Insofern passt das trotzdem des anderen begrifflichen Schwerpunktes schon - schließlich sind es die beiden Seiten ein und der selben Münze. So oder so hat man einen Fluss. Dass der Name EBC nahelegt, dass die Fluss-Steuerung autonom über "Events" gesteuert wird, ist auch nicht verwunderlich. Ob nun nach Push- oder Pull-Prinzip nachfolgende Prozesse können erst aktiv werden, wenn vorangegangene abgeschlossen sind. Und das wird eben "signalisiert", woraufhin die Daten weiterfließen können, zum nächsten Teilprozess. Für mich ergibt sich dort also schon ein Gesamtbild. Mich würde interessieren, ob Ralf das ebenfalls so sieht - oder mehr in eine andere Richtung drängen möchte.

Nun hat Ralf letztens auf Twitter folgendes gepostet:
Zitat
PDF-book on Flow-Based Programming. Something for anyone interesed in Event-Based Components: http://bit.ly/9s7wlR
. Und der Verweis ist wirklich angebracht, denn an genau dieses Buch musste ich denken, als ich das erste mal von EBCs gelesen habe. (Achtung: Lesenswert!) Nun frage ich mich: Will Ralf weiter in diese Richtung drängen? oder wo will er enden mit seinen EBC? Weil im Grunde ist es nichts anderes - nur alter Wein in neuen Schläuchen. Aber ok, da sich das Paradigma (noch) nicht flächendeckend durchgesetzt hat, sollte man es ruhig nochmals und nochmals aufräufeln!
Aber vielleicht will Ralf etwas völlig anderes mit seinen EBC - nur ist mir das dann noch etwas unklar.

Wenn es aber doch in diese Flow-Based-Richtung geht, dann sind EBCs aber noch sehr zurückhaltend. Was es zuerst braucht ist eine ordentliche Laufzeitumbegung (wie C#FBP). Ich bezweifle dass man allein mit dem Event-Mechanismus oder Funktions-Delegaten das ordentlich umsetzen kann.
Den Vorteil des Fluss-basierten sehe ich gerade darin, dass man sich nicht über das konkrete Laufzeitverhalten kümmern muss, (Weshalb parallelisieren so einfach wird) das ist Aufgabe der Laufzeit. (Genau wie Speicherverwaltung das mitlerweile auch ist)

Nun aber mal zum Prozeduralen. Ich verstehe Herbivores Einwand so, dass sich EBCs zu stark vom Objektorientierten lösen. Objektorientierung ermöglicht ja gerade das Zusammenfassen von Funktion und Daten in "Objekte", also Modularitäts-Einheiten. Während EBCs (und flow basiertes) vornehmlich die Funktionalität selbst als Modularitäts-Einheit auffassen. Im Grunde wie bei der Prozeduralen Programmierung - was wohl die Ähnlichkeit ausmacht.
Aber allein mit diesem Ansatz müsste man ebenso funktionale Sprachen als "prozedurale Altlast" beschimpfen.

Nun finde ich aber, dass prozedurale Programmierung im Grunde nur die Wiederverwendung von Code-Abschnitten ermöglicht - mehr nicht. Eine Alternative zu Copy'n'Paste. Während die Funktionale Programmierung der Funktion als solches eine eigene Bedeutung zukommen lässt. Das ist eine neue Qualität! Und so ähnlich ist es bei EBC2 / FBP: Die Funktionseinheiten/Module/EventBasedComponents dienen direkt der Prozess-Modellierung. Sind also sowohl Abbildung und Realisierung des zugrunde liegenden Prozesses. Und auch das ist eine neue Qualität.

Die Nähe zum Objektorientieren Design geht natürlich verloren. Aber genau das ist ja die Idee. Oft genug lassen sich Begebenheiten nicht "natürlich" in Objekte quetschen. Da sitzt man vielleicht mit seinen CRC-Kärtchen und versucht ein sinnvoles Object-Theater umzusetzen, aber alles wirkt gekünstelt. Wenn der Hintergrund ein Prozess ist, sollten wir auch an Prozesse denken dürfen. Und warum dann nicht Prozess-Orientiert designen? (Und mit EBC/FBP dann sogar so implementieren) Also ich bin dafür.

Nun muss das natürlich nicht im Widerspruch zu allem ObjektOrientierten stehen. Die Daten, die im Prozess verarbeitet werden - das müssen ja keine "passiven", reinen Datenklassen sein. Ob jetzt nun Active Records oder sonstige "aktive" Klassen, ist ja egal. Aber auf der Ebene kann ruhig objektorientiert gekapselt werden.

Nunja, den eigentlichen Vorteil sehe ich aber woanders. (Ich zitiere einfach mal aus Morrison's Buch
Zitat von J. Paul Morrison (Flow Based Programming)
[...] in FBP application development there are two distinct roles: the component builder and the component user or application designer. The component builder decides the specification of a component, which must also include constraints on the format of incoming data [...] and the format of output [...] The specification should not describe the internal logic of the component, although attributes sometimes "leak" from internal to external (restrictions on use are usually of this type). The application designer builds applications using already existing components, or, where satisfactory ones do not exist, s/he will specify a new component, and then see about getting it built. Component designers and users may of course be the same people, but there are two very different types of skill involved. [...]
Dass dort unterschiedliche Fähigkeiten gefragt werden, sehe ich absolut genauso. Und EBC/FBP Ermöglicht hier endlich eine Trennung! Mit solchen (EBC-)Komponenten kann ich den Prozess direkt beschreiben. Das ist die Ebene auf der man mit EBC arbeitet. Die von Ralf beschriebene Ebene der Platinen-Verschaltung! Und die ist eben schon etwas anderes als das "Programmieren der darunterliegenden Komponenten". Also sollte man auch ein anderes Paradigma einsetzen (dürfen). Und meines Erachtens versucht genau hier EBC anzusetzen.

Ich sehe im Übrigens durchaus Analogien zu WPF. Denn GUI und Logik sollte nicht nur auf dem Papier getrennt sein, und auch nicht nur im Code nachher wenig Abhängigkeiten haben - man sollte zudem auch anders entwickeln - mit einem anderen Paradigma. Genauso macht es WPF vor. Deklarativ mit XAML. GUIs lassen sich vielleicht so viel besser beschreiben. Das ist der eigentliche Vorteil von WPF. Nachteil ist nur, dass es wohl zu wenig WPF-Designer gibt.

Ich möchte jetzt nicht mit einem pauschalisierenden "Für jede Aktion das richtige Werkzeug" abschließen - auch wenn es stimmt - denn (Das Grundprinzip hinter / Meine Sicht von) EBC hat mehr Potential als nur ein Nischenwerkzeug zu sein.

Soweit meine Sicht von EBCs. Vielleicht geprägt von meinem Vorwissen. Jedenfalls finde ich die ganze "Reduzieren von Abhängigkeiten zwischen Interfaces/Klassen"-Geschichte sowas von unrelevant. Wie Herbivore in einem anderen Post schon klar herausgestellt hat, reduzieren sich keineswegs die Abhängigkeiten.
Ich finde nur, dass die Abhängigkeiten der Prozess-Verarbeitungs-Schritte untereinander auf einer völlig neuen Ebene beschrieben werden. Das macht den Reiz der Trennung zwischen Platine und Bauelement. Wenn alles irgendwie irgendwo Klassen in meinem OODesign sind, dann erkennt man höchstens am Namen "BlaBlaBla-Manager", dass diese Klasse eine besondere, integrierende Aufgabe übernimmt. Mit EBC bekommen diese integrierenden Teile (Platinen) einfach eine eigene Rolle und damit eine neue Qualität. Endlich wird die eigentliche Prozess-Kette explizit - und damit durchschaubarer, verständlicher, variabler, wartbarer, (weitere positiv besetzte Worte, die jede in die Runde wirft, wenns um Modularität geht ... ).

So, das war jetzt einfach mal meine Meinung zu EBC. Vielleicht interessiert die ja wen Zumindest habe ich auch begründet.

beste Grüße
zommi

PS: Was die Windows Workflow Foundation zu all dem Zeug leistet, kann ich nicht sagen. Habe mir das noch nie angeschaut.

PPS: Hab mich vor einiger Zeit mal mit Lucid beschäftigt. Sehr schnuckelig
private Nachricht | Beiträge des Benutzers
malignate
myCSharp.de - Member

Avatar #avatar-3206.png


Dabei seit:
Beiträge: 742

beantworten | zitieren | melden

Zitat von Arithmetika
Daher wird das mit EBC nichts (in meinen Augen), weil man nicht garantieren kann, das jeder (oder fast jeder) auch wirklich weiß was das ist und wenn auch nur einer nix damit anfangen kann, dann kommt dabei nur murks raus. Das ist schon häufig genug bei OOP so und dabei wissen glücklicherweise schon die meisten (hat ja auch sehr lange gedauert), was OOP ist.

Dann würden wir ja immer noch in den Höhlen hocken und unser Fleisch roh essen, weil das der Standard wäre und noch nicht alle wüssten, dass man Fleisch auch braten kann.

Also das ist eine sehr komische Begründung. Ich kenne kein Unternehmen, indem jeder mit allen Technologien vertraut ist. Softwareentwicklung ist ja nicht homogon, sondern heterogen, gerade wenn es große Projekte sind. Da kommuniziert die komponentenorientierte Silverlight APP mit MVVM Pattern und WCF mit dem ohne OOP geschriebenen PHP Service. Dafür brauchts nur eine Vereinbarung und nicht gleich einen Standard.
private Nachricht | Beiträge des Benutzers
Arithmetika
myCSharp.de - Member



Dabei seit:
Beiträge: 69

beantworten | zitieren | melden

Zitat
Dann würden wir ja immer noch in den Höhlen hocken und unser Fleisch roh essen, weil das der Standard wäre und noch nicht alle wüssten, dass man Fleisch auch braten kann.

Ich dachte mir schon, das jemand mit diesem Argument kommt.
Würdest du auch demjenigen folgen, der behauptet, das das Fleisch viel besser schmeckt, wenn man dabei zeitgleich von der Klippe springt?

Fakt ist: mit EBC kann man nichts neues machen, was man nicht vorher schon produktiv und gut machen konnte. Man gewinnt durch EBC nichts in meinen Augen. Das einzige, was man momentan bei der verwendung von EBC in kauf nimmt, ist mehr Risiko durch Unkenntniss mehrerer als im vergleich zu OOP.
Zitat
Ich kenne kein Unternehmen, indem jeder mit allen Technologien vertraut ist.
Habe ich ja auch nciht behauptet. Ich denke nur, das wenn man mit c# programmiert, das man davon ausgehen kann, das die meisten OOP kennen und wir reden hier doch über EBC in c# oder?
private Nachricht | Beiträge des Benutzers
ralfw
myCSharp.de - Member

Avatar #avatar-3115.jpg


Dabei seit:
Beiträge: 71
Herkunft: Hamburg

beantworten | zitieren | melden

Hier die "offizielle" Herausforderung an alle, die meinen, EBC sei keine Alternative zu ihrer eigenen Entwicklungsmethode:

Enter the Matrix!

Seid mutig, zeigt was ihr könnt!
Dieser Beitrag wurde 1 mal editiert, zum letzten Mal von ralfw am .
private Nachricht | Beiträge des Benutzers
ralfw
myCSharp.de - Member

Avatar #avatar-3115.jpg


Dabei seit:
Beiträge: 71
Herkunft: Hamburg

beantworten | zitieren | melden

Zitat von Artihmetika
Würdest du auch demjenigen folgen, der behauptet, das das Fleisch viel besser schmeckt, wenn man dabei zeitgleich von der Klippe springt?

No risk, no fun.

No pain, no gain.

Das war dasselbe, als OOP die Strukturierte Programmierung ersetzt hat.

Das ist jetzt der Fall, da FP OOP den Rang beginnt abzulaufen.

Das war übrigens auch der Fall, als Hochsprachen Assembler verdrängt haben. Was zeterten die alten Kämpen, dass das der Untergang performanter Verarbeitung sei.

Und somit sind wir jenseits der Argumente angekommen. Jetzt geht es um grundsätzliche persönliche Haltungen. Wie risikoavers ist jemand; wie sehr liebt er die Sicherheit, das heimelige Gefühl des Bewährten; wie offen für Neues ist sie?

Da helfen dann keine "Beweise" und nix. Da hilft am Ende nur die Masse, die es halt einfach anders tut als der, der sagt, EBC (oder FP, Rx, Erlang usw.) sei wie der Sprung von einer Klippe.
private Nachricht | Beiträge des Benutzers
ralfw
myCSharp.de - Member

Avatar #avatar-3115.jpg


Dabei seit:
Beiträge: 71
Herkunft: Hamburg

beantworten | zitieren | melden

@zommi: Vielen Dank für deinen Beitrag. Hat mir gut gefallen. Eine differenzierte Sichtweise inkl. Mit-/Weiterdenken. Schau doch mal in der EBC-Diskussionsgruppe hier vorbei. Da können wir in die Einzelheiten gehen.

An dieser Stelle nur soviel: Imperative Programmierung ist eben nicht (!) das Thema von EBC. EBC-Diagramme sollen keine Flowcharts sein. Das ist ja der Trick. Wer beim Modellieren mit EBC an Schleifen und Fallunterscheidungen denkt, ist schon zu tief in der Abstraktion abgestiegen. Damit haben EBC nichts zu tun.

Dass EBC erstmal eine richtige Laufzeitumgebung brauchen würden, sehe ich jedoch nicht. Die Praxis zeigt das Gegenteil. Ich habe noch keine solche Umgebung vermisst.

Bei der Verdrahtung kann sich noch was tun im Sinne einer Hilfestellung und "Reverse MDA". Ein Bus ist auch schon implementiert und macht es in manchen Szenarien einfacher zu verdrahten. Der Übergang von/nach Rx ist hergestellt und schließt EBC insofern an ein für Microsoft zentrales Programmiermodell an.

EBC sind damit natürlich nicht am Ende. "Panta rei" gilt auch hier - quasi im doppelten Sinn :-) Gerade deshalb bin ich ja am kristischen Austausch (!) interessiert.
private Nachricht | Beiträge des Benutzers
Arithmetika
myCSharp.de - Member



Dabei seit:
Beiträge: 69

beantworten | zitieren | melden

Zitat
Das war dasselbe, als OOP die Strukturierte Programmierung ersetzt hat.
Einen essentiellen Punkt scheinst du da außer acht zu lassen. Mit Hochsprachen konnte man schneller zum Ziel kommen. Daher hatte man einen spürbaren und vor allem messbaren Mehrwert. EBC bietet das nicht.
private Nachricht | Beiträge des Benutzers
malignate
myCSharp.de - Member

Avatar #avatar-3206.png


Dabei seit:
Beiträge: 742

beantworten | zitieren | melden

Das hat uns die Erfahrung und wohl auch einige Studien gezeigt. Und das wird es auch bei EBC - oder eben nicht. Wer weiß das schon, aber dafür ist es noch zu früh denke ich. Es muss sich ja in der Alltags und Projektwelt noch beweisen und das dauert eben.
private Nachricht | Beiträge des Benutzers
ralfw
myCSharp.de - Member

Avatar #avatar-3115.jpg


Dabei seit:
Beiträge: 71
Herkunft: Hamburg

beantworten | zitieren | melden

Zitat von Arithmetika
Mit Hochsprachen konnte man schneller zum Ziel kommen. Daher hatte man einen spürbaren und vor allem messbaren Mehrwert. EBC bietet das nicht.

Sorry, du pickst dir raus, was dir passt. Solange du schneller zum Ziel kommst, aber der Code zu langsam ist, nützt die Zielerreichung nix. Den Assemblerjüngern war eben "schneller zum Ziel" ziemlich egal. Sie haben behauptet, dass die Ergebnisse zu langsam seien.

Wenn ich dir etwas von Evolvierbarkeit sage, du aber einen anderen Wert hast, dann nützt dir das auch nix. Ich weiß nicht, was dein Wert heute ist. Aber das Argument ist, dass irgendwas wichtiger sei als Evolvierbarkeit (das mal als beispielhafter Wert).

Und noch ein Beispiel aus der Geschichte: Musik wurde seit Urzeiten nur mündlich tradiert. Dass man sie aufschreiben könnte oder sollte... das kam niemanden so recht in den Sinn. Dabei haben alle mit den Problemen des Stille-Post-Effektes gekämpft.

Dann trat Guido von Arezzo (http://de.wikipedia.org/wiki/Guido_von_Arezzo) auf. Der erfand die Notenschrift und war daher in der Lage, Musik verlustfrei weiterzugeben.

Hat da die Musikwelt gejubelt? Ne. Die haben sie gewehrt. Iiiiih, da musste man ein neues System lernen. Wie dooof. Da lebte man lieber mit den Problemen des alten weiter.

Nun ja, am Ende hat sich Notenschrift durchgesetzt, wie wir wissen. Und erst dadurch wurde Musik wie Mozarts Zauberflöte möglich.

Jetzt will ich nicht sagen, EBC seien von gleicher Bedeutung wie die Notenschrift. Aber dass Leute widerständig sind, ist für mich auch kein Zeichen dafür, dass EBC nix taugen. Es kommt halt immer auf die Argumente an. Und es kommt auf die rein persönlichen Werte an. Für manche ist Objektorientierung halt ein Wert. Auch ok. Für manche Performance. Für manche aber auch was Neues/Anderes. Und so gehen die weiter und probieren es.
private Nachricht | Beiträge des Benutzers
Haggy
myCSharp.de - Member

Avatar #avatar-2608.png


Dabei seit:
Beiträge: 1.134
Herkunft: Karlsruhe

beantworten | zitieren | melden

schade dass diese eigentlich sehr interessante Diskussion still steht.
Es geht doch auch nicht darum ob EBC ein "Allheilmittel" oder die "Pest" sind.

Veränderungen sind immer schwer, es braucht überwindung sich objektiv damit zu beschäftigen. (ohne jetzt EBC's zu werten).

Gitb es jemanden der EBC's im Produktiveinsatz hat ?
Und wenn ja wie sind da die Erfahrungen?

Ich setze EBC's seit 3 Monate ein. Zum einen in Teilbereichen eines bestehenden Systems (> 300k Zeilen Code -5 Entwickler) und zum andern in Greenfield applikationen.

Ein Beispiel in dem EBC's für mich eindeutig Vorteile bringen und inzwischen selbst die Skeptiker überzeugt hat, sind Cross Cutting Concerns.

Tracing, Login,Security,UserManagement, Caching,... Code schrumpft teilweise um 50% (!) und erleichtert die verwendung von Basis komponenten.

Im Sinne von SRP, SOC; eindeutig Vorteile

Schwieriger wird die Beurteilung bei EBC's in Domain Spezifischen komponenten, hier sehe ich vor und nachteile (bsp. pot. komplexe Boards)
Aber das sprngt den Rahmen der Diskussion.

Es würde mich freuen wenn eine Diskussion wie diese Konstruktiv und mit von 2 Vertretern gegensätzlicher Standpunkte in konstruktiver und angstfreier manier geführt werden würde.

Wichtig wäre zum beiden wo liegt ein Konsens ?
Z.Bsp. CCC und Topologie aus der DomainLogik zu halten ist für mich inzwischen eine zwingende Anforderung an guten code. Ob das via AOP oder EBC (1 oder 2) oder IBC passiert, ist erst die nächste frage.

Gibt es denn überhaupt soweit einen Konsens ?

Und das wäre für jeden ein Mehrgewinn.
Dieser Beitrag wurde 2 mal editiert, zum letzten Mal von Haggy am .
Mein Stackoverflow Profil
Skype Name : Boas.Enkler (bitte einen hinweis in der Kontaktanfrage damit ich euch vom Spam unterscheiden kann)
private Nachricht | Beiträge des Benutzers
serial
myCSharp.de - Member



Dabei seit:
Beiträge: 902

beantworten | zitieren | melden

Ich bin auch wieder mal da!
Wollte mit meinem thread keinen streit vom zaun brechen =(

@ralfw: Auch wenn ich mich vielleicht mit dem "engagement", wie hier das für und wider diskutiert wird nicht ganz anfreunden kann, möchte ich trotzdem sagen das die ebcs mich wahnsinnig interessieren...und darum sollte es ja hier gehen.
Ich finde es gut, dass es überhaupt leute gibt, die sich sowas einfallen lassen. Es ist dann natürlich klar, dass man "sein baby" ins trockene bringen möchte.

@Haggy: danke, denn dein beitrag ist eigentlich genau das, worum es mir eingangs ging. Ich kann mir eben ebcs für ccc super vorstellen. Aber mir macht es eben probleme bei domainlogik. Produktiv habe ich sie noch nicht im einsatz, eben weil mir da noch zu viele fragezeichen über dem kopf stehen. Sollten diese allerdings beseitigt werden, würde ich ebcs gern produktiv einsetzen.
private Nachricht | Beiträge des Benutzers

Moderationshinweis von herbivore (18.09.2010 - 17:49)

Für das Thema mit der Domainlogik gibt es aber den anderen Thread: EBCs in Informationssystemen (verteilt). Bitte dafür den benutzen.

Aber auch in diesem Thread hier geht es schon wieder sehr konfus zu. Der Titel hier ist ja "EBCs 2.0, deren Nähe zur prozeduralen Programmierung und deren Nutzen". Leider wurde EBC 1.0 und EBC 2.0 hier ziemlich in einen Topf geworfen.

Haggy
myCSharp.de - Member

Avatar #avatar-2608.png


Dabei seit:
Beiträge: 1.134
Herkunft: Karlsruhe

beantworten | zitieren | melden

Das dieses Diskussion aus dem Ruder lieft hat ja nichts mit deiner Frage zu tun.



Für mein Gefühl gehts da eher um persönliche Dinge.


Ein posting zu EBC's wurde vor ein paar wochen auch kommentarlos gelöscht.

Ich finde es sehr schade dass bei einem sehr guten Forum, Themen wegen persönlichen Ansichten nicht diskutiert werden könne...[/color]

Bei dem gelöschten Thread, handelte sich um ein Mißverständniss bzw. ein Bedienungsfehler meinerseits, wurde mit herbivore geklärt.
Dieser Beitrag wurde 2 mal editiert, zum letzten Mal von Haggy am .
Mein Stackoverflow Profil
Skype Name : Boas.Enkler (bitte einen hinweis in der Kontaktanfrage damit ich euch vom Spam unterscheiden kann)

Moderationshinweis von herbivore (20.09.2010 - 08:51)

Ich bin froh, dass wir das Missverständnis ausräumen konnten.

Wenn ihr glaubt, dass mal etwas schief gelaufen ist, wendet euch bitte - immer zuerst per privater Nachricht - vertrauensvoll ans Team. Wie das am einfachsten geht, steht in Kontakt zum Team. Dadurch lassen sich Missverständnis klären, bevor sie durch einen öffentlichen Post unnötig weitere Irritationen im Forum auslösen.

private Nachricht | Beiträge des Benutzers
Uwe81
myCSharp.de - Member



Dabei seit:
Beiträge: 282
Herkunft: Ludwigshafen

beantworten | zitieren | melden

Bezieht sich auf eine Frage einige Beiträge weiter Vorne.
Zitat
Warum sollte eine EBC-Architektur zu mehrfacher Datenhaltung führen? Das verstehe ich nicht. Wenn du früher ein Repository hattest, dann kannst du mit EBC 1.0 und auch EBC 2.0 weiterhin ein zentrales Repository haben.

Damit Komponenten entkoppelt sind, darf IMHO nicht nur eine Komponente das Interface der anderen nicht kennen müssen, sondern auch sehr wenige Annahmen über deren Zustände machen.

Nun gebe es ein zentrales Repository, auf das ale Komponenten (über EBC-Methoden, also von außen verdrahtet) zugreifen. Dann hat eine Komponente also Pins
Out_PointGenerated
Out_PointSelected
Out_PointRestricted
In_PointStateChanged
In_PointSelected
In_PointAdded
Func<Point, PointState> GetState
...

Nun muss ich Annahmen machen: Wenn ich Out_PointGenerated aufrufe, kommt In_PointAdded zurück. Bei Out_PointSelected wird In_PointSelected aufgerufen. Bei Out_PointRestricted wird (wenn der Punkt nicht bereits restringiert ist) In_PointStateChanged aufgerufen. Nachdem Out_PointGenerated aufgerufen wurde, darf ein aufruf von GetState nicht fehlschlagen.


Dann sind die Komponenten aber nicht mehr entkoppelt. Zwar braucht eine Komponente die andere nicht zur Compile-Zeit, aber durch die ganzen Verhaltensannahmen sind sie gekoppelt.

Das ist bei einem Interface nicht anders. Aber: Wenn ich bei einem Interface die Methode "AddPoint" aufrufe (entspricht Out_PointGenerated) ist es "natürlich" zu erwarten, dass "PointsAdded"-Event geworfen wird. Wenn ich "AddPoint" aufgerufen habe kann ich erwarten, das der Punkt da drin ist und "GetState" funktioniert.


Um diese Kopplung zu vermeiden, müsste jede Komponente alle Punkte verwalten, alle Zustände kennen und nur auf ihren eigenen Zuständen arbeiten. Dann gäbe es nach außen sehr wenige nachrichten, die jeweils auf Validität geprüft werden können.





Vielleicht ist das mein Hauptkritikpunkt: Wenn meine Komponente zwei Methoden hat:
Out_DoSomething
GetSomething

und nach Out_DoSomething(a) muss GetSomething(a) funktionieren oder einen bestimmten Wert haben, nützen mit EBC nichts mehr. Denn dann erwarte ich, dass die Komponenten in einer bestimmten Art und Weise Verdrahtet sind. Damit ist die Kopplung da. Und dann ist mir lieber, die Abhängigkeit steht mittels Interface relativ explizit im Code.
private Nachricht | Beiträge des Benutzers
Uwe81
myCSharp.de - Member



Dabei seit:
Beiträge: 282
Herkunft: Ludwigshafen

beantworten | zitieren | melden

Noch als Ergänzung zu dem Thema Abhängigkeit:

Habe mit einem Bekannten mal die Diskussion gehabt, ob Templates oder Polymorphie besser sei (in C++, auch wenn das natürlich so pauschal nicht zu diskutieren war).

Sein Argument war, dass bei Templates keine Abhängigkeiten entstehen würden.

Also bei Polymorphie: Die Methode
Sort(MeinTyp, ICompoarer<MeinTyp>)
muss das interface IComparer kennen.

Bei Templates: Die Methode
template<typename TComparer>
Sort(MeinTyp, TComparer)
muss den Comparer nicht kennen.


Für mich war das aber keine Reduktion der Abhängigkeit. Sie ist nicht zur KompileZeit vorhanden, aber sie ist implizit da, weil angenommen wird, dass TComparer bestimmte eigenschaften hat.


So ähnlich sehe ich es mit EBC:
Wenn eine Komponente nur dann funktioniert, wenn ihre Pins in einer gewissen weise verdratet sind, ist sie nicht mehr unabhängig vom System. Dann verschleiert EBC die Abhängigkeiten eher.


Daher bleibt mein Statement: EBC weist auf Probleme hin (Abhängigkeiten zu Interfaces sind auch Abhängigkeiten). Wenn man diese einfach Auflösen kann in unabhängige "Pins" (auch wenn ich bei Methoden und Events in alter notation bleibe) mache ich es gerne und reduziere die Abhängigkeiten. Ist das Interface aber zu komplex bleibe ich lieber bei IBC mit expliziten Abhängigkeiten.
Dieser Beitrag wurde 1 mal editiert, zum letzten Mal von Uwe81 am .
private Nachricht | Beiträge des Benutzers
ralfw
myCSharp.de - Member

Avatar #avatar-3115.jpg


Dabei seit:
Beiträge: 71
Herkunft: Hamburg

beantworten | zitieren | melden

@Uwe81: Logische Abhängigkeiten gehen mit EBC natürlich nicht einfach so weg. Darüber müssen wir hier also nicht diskutieren.

Aber ich ahne, dass du dir das EBC-Leben zu schwer machst. Du denkst nämlich in deinem Beispiel in EBC 1.0. Und du nutzt keine ad hoc Pins für die Anlieferung von Responses zu Requests.

Diese Probleme verschwinden mit EBC 2.0.

Um dir das zu erläutern, müsstest du aber das Problem erklären, das zu zu lösen versuchst.
private Nachricht | Beiträge des Benutzers
Peter Bucher
myCSharp.de - Experte

Avatar #jVxXe7MDBPAimxdX3em3.jpg


Dabei seit:
Beiträge: 5.940
Herkunft: Zentralschweiz

beantworten | zitieren | melden

Hallo Arithmetik
Zitat von Arithmetik
Einen essentiellen Punkt scheinst du da außer acht zu lassen. Mit Hochsprachen konnte man schneller zum Ziel kommen. Daher hatte man einen spürbaren und vor allem messbaren Mehrwert. EBC bietet das nicht.
Sagt wer? Du?

Erstmal: EBCs bieten auch Mehrwert(e), ob das jetzt die Produktivität sein mag oder nicht, wage ich noch nicht zu beurteilen.

Ich weiss nur, das ich mit einem Kollegen zusammen per EBC, eine komplexe Implementation in sehr kurzer Zeit, vollkommen ohne Abhängigkeiten innerhalb der Komponenten selber entwickeln konnte, und testbar war am Ende alles, ohne Zusatzaufwand.

Was ich damit sagen will: Produktivität muss kein Mehrwert von EBC sein. Vielleicht ist es ja einer, aber die Primärmehrwerte gehen eher in Richtung der kompletten Entkoppelung der kleinen Komponenten, nur die Blackbox weiss über die Verbindungen Bescheid.

Bitte schildere doch mal deine Ansicht.


Gruss Peter
--
Microsoft MVP - Visual Developer ASP / ASP.NET, Switzerland 2007 - 2011

- https://peterbucher.ch/ - Meine persönliche Seite
- https://fpvspots.net/ - Spots für FPV Dronenflüge
private Nachricht | Beiträge des Benutzers
Golo Roden
myCSharp.de - Member

Avatar #avatar-2167.png


Dabei seit:
Beiträge: 4.207
Herkunft: Riegel am Kaiserstuhl

beantworten | zitieren | melden

Hallo "Kollege" ;-)!

@ Arithmetik: Jups, kann mich da Peter nur anschließen. EBCs erfordern ein Umdenken in Richtung streambasierter Datenverarbeitung, aber hey, auch die OOP hat ein Umdenken erfordert. TDD ebenfalls. Funktionale Programmierung erfordert ein Umdenken. Na und?

EBCs haben diverse sehr deutliche Vorteile, der wichtigste aus meiner Sicht ist die extreme Entkopplung. Die Eignung für TDD & Co sind daraus eigentlich nur Folgen.

Aber wie Ralf ja schon angeboten hat: Wer Zweifel hat und ein ehrliches Interesse an einem Vergleich, ist herzlich zu einem "Shootout" eingeladen.
Wissensvermittler und Technologieberater
für .NET, Codequalität und agile Methoden

www.goloroden.de
www.des-eisbaeren-blog.de
private Nachricht | Beiträge des Benutzers
Haggy
myCSharp.de - Member

Avatar #avatar-2608.png


Dabei seit:
Beiträge: 1.134
Herkunft: Karlsruhe

beantworten | zitieren | melden

Dieses Shootout fände ich sehr spannend ! :-)
Wenn es dazu was gibt könnt ihr ja nochmal bescheidgeben.
Mein Stackoverflow Profil
Skype Name : Boas.Enkler (bitte einen hinweis in der Kontaktanfrage damit ich euch vom Spam unterscheiden kann)
private Nachricht | Beiträge des Benutzers
ralfw
myCSharp.de - Member

Avatar #avatar-3115.jpg


Dabei seit:
Beiträge: 71
Herkunft: Hamburg

beantworten | zitieren | melden

Einfach die Kommentare zu meinem Blogbeitrag beobachten. Auch hier gilt ja DRY :-) Informationen nicht unnötig verdoppeln.
private Nachricht | Beiträge des Benutzers
Uwe81
myCSharp.de - Member



Dabei seit:
Beiträge: 282
Herkunft: Ludwigshafen

beantworten | zitieren | melden

Zitat
@Uwe81: Logische Abhängigkeiten gehen mit EBC natürlich nicht einfach so weg. Darüber müssen wir hier also nicht diskutieren.

Es ist nur die Frage, ob diese unmittelbar sichtbar sind (bei einem Interface, dass ich verwende, sind sie das), bei einzelnen Methoden nicht.

Ich spinne jetzt mal rum: Wenn ich mir mein PC anschaue, sind da außen sehr viele Signale mit starken logischen Abhängigkeiten. Ist aber nicht schlimm, denn wenn ich den Monitor anschließe muss ich nicht jedes einzelne Signal verbinden, sondern ich verbinde den ganzen Stecker.

Das würde ich mir bei EBC auch wünschen (ohne dass ich eine Ahnung habe, wie das implementiert wird): Das eine Komponente eben nach außen nicht die einzelnen Methoden bereitstellt, sondern ganze Bündel von Signalen. Die die Platine dann auch als Bündel verbinden kann.

Dann muss die Platine weniger über Abhängigkeiten der Komponenten wissen und ist auch deutlich einfacher. Außerdem wären eben zusammengehörige und unmittelbar abhängige Signale auch logisch zusammengefasst.


Das die Platine einzelne Singnale verbinden muss entspricht irgendwie Methodenaufrufe, die X primitive Datentypen bekommen. Structs oder gar Objekte machen das ganze aber viel übersichtlicher.
private Nachricht | Beiträge des Benutzers
ralfw
myCSharp.de - Member

Avatar #avatar-3115.jpg


Dabei seit:
Beiträge: 71
Herkunft: Hamburg

beantworten | zitieren | melden

Bündel von Signalen könnten als Interfaces realisiert werden.

Von logischen Abhängigkeiten befreit das aber nicht. Die steckt ja nicht in der Kombination von Drähten zu Drahtbündeln/Steckern, sondern in den Signalen. Ein Monitor erwartet nicht nur einen Stecker einer bestimmten Form mit n Pins, sondern dass darin Signale mit Spannung/Strom fließen, wie gewünscht, und die Codierung eine bestimmte ist.

Die Analogie sollte also auch nicht zu weit getrieben werden.

Natürlich kann man ein EBC-Bauteil mit einem Interface versehen und so komplett irgendwo anstecken. Aber dann sind wir wieder bei IBC. Wer das machen will, kann es gern tun. Ich sehe darin keinen Vorteil. Bzw. damit verliere ich, was mit EBC geben: topologische Unabhängigkeit.
private Nachricht | Beiträge des Benutzers
Uwe81
myCSharp.de - Member



Dabei seit:
Beiträge: 282
Herkunft: Ludwigshafen

beantworten | zitieren | melden

Zitat
Natürlich kann man ein EBC-Bauteil mit einem Interface versehen und so komplett irgendwo anstecken. Aber dann sind wir wieder bei IBC.

Nein, das hast du mich glaube ich falsch verstanden.

Meine Idee (wie gesagt, evtl. derzeit mit C# nicht möglich):
Angenommen, es gibt zwei Komponenten, die kommunizerien.
Comp1 {
    Out_MessageA;
    In_MessageB;
}

Comp2 {
    Out_MessageB;
    In_MessageA;
}

Die Nachrichten hängen stark voneinander ab.


Dann muss das Board derzeit beide Drähte einzeln verbinden. Ich will aber Das ganze Bündel als ein Nachrichtensystem sehen.

Also eine Sammlung von Signalen
MySignalBus{
    Out_MessageA;
    In_MessageB;
}

Und Komponenten
Comp1{
    +SignalBus;
}


Comp2{
    -SignalBus;
}

(wobei bei -SignalBus eben Out und In invertiert sind).

verbunden sind die Komponenten dennoch über das Board, aber das muss nur noch die Busse ineinanderstecken, nicht mehr die eizelnen Leitungen.



Bei IBC hingegen müsse Comp1 die Comp2 kennen (oder umgekehrt). Das entfällt bei meiner Idee.
private Nachricht | Beiträge des Benutzers
ralfw
myCSharp.de - Member

Avatar #avatar-3115.jpg


Dabei seit:
Beiträge: 71
Herkunft: Hamburg

beantworten | zitieren | melden

In diesem Repo findest du einen kleinen Bus für EBC: http://ebclang.codeplex.com, Verzeichnis MiniBus

Bei dem werden allerdings auch einzelne Pins verdrahtet. Find ich aber nicht schlimm. Verdrahten von ganzen Interfaces hab ich nicht als nützlich erlebt. Kannste ja aber gern versuchen.
private Nachricht | Beiträge des Benutzers
mg.net
myCSharp.de - Member



Dabei seit:
Beiträge: 153

beantworten | zitieren | melden

Hallo ralfw,

also ich empfinde EBC (2.0) als eine interessante Möglichkeit, Beziehungsgeflechte flexibler und unabhängiger zu gestalten, als dies bisher möglich und üblich ist.

Dennoch zögere ich noch, vor allem aus praktischen Erwägungen heraus. Es stellen sich mir noch einige Fragen, die, vor allem, den Produktionsalltag betreffen:
  • Wie groß gestaltet sich der Einarbeitungsaufwand für die Entwickler?
  • Was ist zu standardisieren und in welchem Umfang?
  • Welche Auswirkungen ergeben sich für die Tests, von den Unittests bis zu den Akzeptanztests, von der Testfallplanung bis zur (automatisierten) Testdurchführung
  • In welcher Weise ist das Deployment betroffen, im Hinblick auf die Granularität der Anwendung (also deploybare Einheiten) und im Hinblick auf die etablierten Continous-Delivery-Prozesse, die bereits automatisiert sind
  • ...

Gibt es denn eine Implementierung die du empfehlen kannst und die sich so als Lehrstück und Spielwiese eignet (und deren Quellen natürlich offen sind)?
private Nachricht | Beiträge des Benutzers
ralfw
myCSharp.de - Member

Avatar #avatar-3115.jpg


Dabei seit:
Beiträge: 71
Herkunft: Hamburg

beantworten | zitieren | melden

ad Einarbeitungsaufwand: Den kannst du nur selbst für dich herausfinden. Einfach machen.

ad Standardisierung: Ein Schritt nach dem anderen. Erstmal damit arbeiten, Erfahrung in die Community einbringen.

ad Testauswirkungen: Eine Auswirkung ist ganz klar: Kein Mock-Framework mehr nötig. Alles andere bleibt im Grunde beim Alten. Warum auch nicht?

ad Deployment: Warum sollte sich daran was ändern? Auch die Einteilung des Codes in Assemblies hat mit EBC nichts zu tun.

Ich empfehle, die Texte, die online stehen, zu EBC zu lesen. Da sind ne Menge Beispiele. Und wenn du selbst was machst, publiziere es.
private Nachricht | Beiträge des Benutzers
jaensen
myCSharp.de - Experte

Avatar #avatar-2657.png


Dabei seit:
Beiträge: 2.760
Herkunft: München

beantworten | zitieren | melden

@zommi: Guter Beitrag!
Zitat von zommi
Aber vielleicht will Ralf etwas völlig anderes mit seinen EBC - nur ist mir das dann noch etwas unklar.
Das ist es mir momentan auch noch.


Ich habe noch keinen wirklichen konzeptionellen Unterschied (außer durch die Verwendung anderer technischer Mittel zur Implementierung also: .Net, Delegates, Events etc.) z.B. zu LabVIEW, einigen ausgefeilten Workflow-Engines etc. entdecken können (das Buch "Flow Based Programming" habe ich nicht gelesen).
Zitat von ralfw
An dieser Stelle nur soviel: Imperative Programmierung ist eben nicht (!) das Thema von EBC. EBC-Diagramme sollen keine Flowcharts sein. Das ist ja der Trick. Wer beim Modellieren mit EBC an Schleifen und Fallunterscheidungen denkt, ist schon zu tief in der Abstraktion abgestiegen. Damit haben EBC nichts zu tun.
Eines meiner großen ? ist es eben auf welchem Abstraktionsniveau ich EBCs einsetzen sollte. Ich finde solche Ansätzen nämlich in der Regel sehr reizvoll aber nur auf einem Niveau in dem ich möglichst Blackbox-artig Services miteinander "verdrahte" und Nachrichten (in welchem Format auch immer) zwischen den Services austausche.

Der Übergang zwischen Komponenten und Services (brauche ich einen Service auf einer höheren Ebene öfter so wird er dort zur Komponente) ist doch ohnehin fließend je nach dem auf welche Abstraktionsebene man geht. Ob ich jetzt auf einer "Platine" verdrahte oder auf einer "Zeichenfläche" ist unerheblich. Ob mein Graph (was es ja letztendlich ist) interpretiert wird oder erst kompiliert ist auch unerheblich für das Konzept.

Niedrigere Abstraktionen einen solchen Konzepts habe ich bei meinem alten Arbeitgeber schon erlebt und das ist trotz der Unterstützung ausgefeilter grafischer Editoren, in Bezug auf die geplanten Aufwände oft in die Hose gegangen. Deswegen stehe ich EBCs auch etwas kritischer gegenüber.

Die Frage lautet meinerseits also: Welche Arten von Komponenten/Tätern soll ich bauen?
Überspitzt formuliert (allerdings habe ich es bis zu dieser Ebene auch schon erlebt) soll ich eine Komponente mit den Eingangspins "Wert1", "Wert2", "Wert3", ..., "Rechenart" und dem Ausgang "Ergebnis" bauen oder sollte ich mich eher auf dem Level von "Kunde" -> "Kreditantrag" -> "Genehmigung einholen" -> "Kredit vergeben/Kredit ablehnen" bewegen?

Das erste Extrem bewegt sich meiner Ansichtsweise nach schon nah an der prozeduralen Programmierung das letzte ist mit prozeduraler Programmierung nicht zu vergleichen da ein Prozess abgebildet wird (Eine Fallunterscheidung ist da allerdings trotzdem drin).

Fast alles einschließlich und zwischen den beiden genannten Extremen lässt sich gut mit einer breiten Palette an Tools abwickeln (von BizTalk über die WF und vielen anderen proprietären Workflow-Engines bis hin zur Programmierung von Hand auf konventionellem Wege oder evtl. auch EBCs quer durch alle Abstraktionsebenen der funktionalität). Nur ein Problem gibt es bei allen Varianten (dazu zitiere ich einfach mal Wikipedia):
Zitat von wikipedia
Das Interface der Komponente ist eine verbindliche Schnittstelle (Interface) zum Rest der Software. Die Schnittstelle kann daher mit einem Vertrag zwischen der Komponente und dem Rest der Software verglichen werden.
Durch die explizite Definition der Kontextabhängigkeiten wird deutlich, wie unabhängig eine Komponente tatsächlich von ihrer Umgebung ist.
Womit wir wieder bei der Frage des Abstraktionsgrades wären.

Eine etwas größere Beispielanwendung wie z.B. die von Rainbirds .NET Applikationsserver wäre schön damit man besser erkennen kann wo und wann EBCs eingesetzt werden. Eine solche Anwendung rein mit EBCs implementiert kann ich mir nämlich nicht vorstellen.

Du bist zwar nicht in der Pflicht eine solche Beispielanwendung zu erstellen aber sie würde die Akzeptanz der EBCs wahrscheinlich erhöhen und die Einstiegshürde niedriger setzen was ja eigentlich nur in deinem Interesse sein kann. Evtl. kommt bei deinem Wettbewerb etwas ähnliches raus und nimmt mir eine Hürde mir EBCs in der Praxis mal genau anzusehen.
private Nachricht | Beiträge des Benutzers
ralfw
myCSharp.de - Member

Avatar #avatar-3115.jpg


Dabei seit:
Beiträge: 71
Herkunft: Hamburg

beantworten | zitieren | melden

Zitat von Jaensen
Eines meiner großen ? ist es eben auf welchem Abstraktionsniveau ich EBCs einsetzen soll

Warum darüber grübeln? Setze EBC dort ein, wo sie dir nützen. Ich tue das von der Ebene der Bounded Contexts bis runter zu Methoden. EBC (oder Flows) sind zunächst mal ein Modell, eine Art zu denken.

Du fragst ja auch nicht, auf welcher Ebene du mit dem "Objektdenken" anfangen sollst. Die Welt modelliert mit "Objekten" auf der Ebene verteilter Funktionalität (sonst gäbe es kein RPC, keine Webservices und auch kein WCF in der Form, wie es vordringlich verwendet wird) und auf der niedrigen Ebene von Datenklassen.

Dieselbe Freiheit kannst du dir mit EBC nehmen.
Zitat
Die Frage lautet meinerseits also: Welche Arten von Komponenten/Tätern soll ich bauen?
Überspitzt formuliert (allerdings habe ich es bis zu dieser Ebene auch schon erlebt) soll ich eine Komponente mit den Eingangspins "Wert1", "Wert2", "Wert3", ..., "Rechenart" und dem Ausgang "Ergebnis" bauen oder sollte ich mich eher auf dem Level von "Kunde" -> "Kreditantrag" -> "Genehmigung einholen" -> "Kredit vergeben/Kredit ablehnen" bewegen?

Datenfluss bedeutet nicht Wert1, 2, 3 setzen. (Genausowenig wie verteilte Funktionalität bedeutet, Properties auf entfernten Objekten zu setzen.) Ich weiß nicht, woher der Gedanke kommt. Dazu gibt es kein einziges Beispiel. Und nicht nur bei EBC nicht, sondern überhaupt bei allem, was mit Flows zu tun hat nicht. Liest denn das keiner?

Deinen Verweis auf Wikipedia verstehe ich nicht. Interfaces sind für EBC zunächst mal irrelevant.

Wenn alle nur warten, dass irgendwer eine größere Anwendung baut, bevor sie sich mit EBC beschäftigen... dann haben wir ein Henne-Ei-Problem. Aber ist halt immer so: free riding. Lass die anderen schaffen...

Aber egal. Wer über EBC diskutieren will, sollte sich hier tummeln: groups.google.com/event-based-components. Dort wird konstruktiv darüber nachgedacht.
private Nachricht | Beiträge des Benutzers
Rainbird
myCSharp.de - Experte

Avatar #avatar-2834.jpg


Dabei seit:
Beiträge: 3.728
Herkunft: Mauer

EBCs in der Praxis

beantworten | zitieren | melden

Zitat von jaensen
Das ist es mir momentan auch noch.
Es ist momentan noch sehr viel Bewegung im ganzen EBC-Konzept. Das macht es schwierig, den Überblick zu behalten. Auch die Tatsache, dass dauernd neue Entwurfsaspekte, Pattern und Varianten hinzukommen, kann etwas verwirrend sein.
Zitat von jaensen
Ich habe noch keinen wirklichen konzeptionellen Unterschied (außer durch die Verwendung anderer technischer Mittel zur Implementierung also: .Net, Delegates, Events etc.) z.B. zu LabVIEW, einigen ausgefeilten Workflow-Engines etc. entdecken können
Verringerung von Abhängigkeiten zwischen Komponenten durch den Einsatz von Delegaten und ausgelagerter Verdrahtung. Das würde ich als den Kern des Konzepts bezeichnen. Simpel aber genial.
Zitat von jaensen
Eines meiner großen ? ist es eben auf welchem Abstraktionsniveau ich EBCs einsetzen sollte.
Mir geht es genauso.
Zitat von jaensen
Der Übergang zwischen Komponenten und Services (brauche ich einen Service auf einer höheren Ebene öfter so wird er dort zur Komponente) ist doch ohnehin fließend je nach dem auf welche Abstraktionsebene man geht.
Service und Komponente ist in meinen Augen dasselbe. Ein Stück Software mit einer klar definierten Schnittstelle, welche so autonom wie möglich ist.
Zitat von jaensen
Die Frage lautet meinerseits also: Welche Arten von Komponenten/Tätern soll ich bauen?
... soll ich eine Komponente mit den Eingangspins "Wert1", "Wert2", "Wert3", ..., "Rechenart" und dem Ausgang "Ergebnis" bauen ...
Würde ich eher nicht tun. Zu filigran, zu fitzelig. Da schreibst Du am Ende mehr Verdrahtungscode, als Geschäftslogik.
Zitat von jaensen
... oder sollte ich mich eher auf dem Level von "Kunde" -> "Kreditantrag" -> "Genehmigung einholen" -> "Kredit vergeben/Kredit ablehnen" bewegen?
Das hört sich - finde ich - viel besser an. Anforderungen lassen sich aber nicht unbedingt immer gleichmäßig in Codekonstrukte umsetzen. Ganz interessant ist in dem Zusammenhang folgender Blog-Beitrag: Das Domänobjektmodell anders gedacht [OOP 2010]
Es gibt allerdings gar nicht immer eine GUI!
Zitat von wikipedia
Das Interface der Komponente ist eine verbindliche Schnittstelle (Interface) zum Rest der Software. Die Schnittstelle kann daher mit einem Vertrag zwischen der Komponente und dem Rest der Software verglichen werden.
EBCs hängen nur über ihre Pins zusammen. Was eine Schnittstelle für eine Klasse ist, das ist ein Delegat für eine Methode. Man hat also viele kleine Verträge, statt eines großen Vertrages. Auf Schnittstellen könnte man deshalb sogar komplett verzichten. Das Problem sind vielmehr die Nachrichtentypen, welche trotz ausgelagerter Verdrahtung gemeinsam genutzt werden. Dafür gibt es keine Lösung! Kommunikationspartner müssen die gleiche Sprache bzw. das gleiche Protokoll sprechen. Natürlich könnte man z.B. mit untypisierten DataTables arbeiten, aber da müssen die Komponenten auch die Spalten kennen bzw. richtig interpretieren.
Zitat von jaensen
Eine etwas größere Beispielanwendung wie z.B. die von Rainbirds .NET Applikationsserver wäre schön damit man besser erkennen kann wo und wann EBCs eingesetzt werden. Eine solche Anwendung rein mit EBCs implementiert kann ich mir nämlich nicht vorstellen.
Ich bin dabei, sowas zu erstellen. Es soll eine kleine verteilte Mini CRM-Anwendung werden, die aus verteilten EBCs mit Zyan aufgebaut wird. 8)
Das wird auch für mich der ultimative EBC-Praxistest.
private Nachricht | Beiträge des Benutzers