Flow Runtime in grossen Projekten

[Andreas Schädler]

Hallo zusammen

ich habe erste Schritte mit FD gemacht und fühle mich wohl, obschon immer wieder Fragen und Unsicherheiten bezüglich der Verdrahtungen entstehen, vor allem über die Schichten hinweg. Wenn aus der Logic auf einen DataAdapter zugegriffen werden muss, ist die Versuchung gross, Bauteil und Platine zu vermischen.

Ich denke, dass hier die Flow Runtime (danke Ralf) weiter hilft, da die Platinen weg fallen. Hier aber die nächste Unsicherheit:

In allen Beispielprogrammen werden jeweils in der Main-Methode alle Klassen instanziert und der FlowRuntimeConfiguration übergeben. Bei grossen Projekten stelle ich mir das aber nicht praktikabel vor. Zum einen währe dies wohl eine unüberschaubare Menge und zum andern wird die ganze Applikation in den Speicher geladen.

Wie teilt Ihr die Konfiguration pro Funktionalität auf? Z.B. pro Menüpunkt im Hauptfenster oder so.  

Vielen Dank und Gruss

Andreas

[Ralf Westphal]

Schön, dass du dich an FD versuchst.

Allerdings höre ich schon ein Missverständnis heraus: du sprichst von Schichten. Die haben aber mit FD nichts zu tun. Da denkst du noch in kontraproduktiven Kategorien. Vergiss Schichten.

Und vergiss die Terminologie Bauteil/Platine. Die gehört zu einer speziellen Implementation von FD Modellen. Sprich besser von Operationen und Flows.

Wie kann es sein, dass Logik auf einen DataAdapter zugreift? Das verstehe ich nicht. Du kannst ja nur von einer Operation sprechen. Aber Operationen haben keine Abhängigkeiten.

Wenn du hingegen von Flows sprichst, dann gibt es zwar Abhängigkeiten - aber die machen nichts. In einem Flow können munter Operationen ganz unterschiedlicher Art gemischt werden.

Die massive Instanzierung in Main ist etwas nervig. Stimmt. Mehrere Abhilfen sind möglich:

1. Automatisierung: mit einem Hilfsmittel ähnlich einem DI Container könnte die Registrierung automatisiert werden. Der Container würde die Operationen sammeln und bei der Config registrieren. Dann müsste man zumindest dafür keinen Code hinschreiben.

So einen Container habe ich auf dem Zettel, bin bisher aber nicht dazu gekommen. Anderes war wichtiger.

2. Ohne Automatisierung kannst du die Registrierung auf Klassen/Komponenten verteilen. Damit fällt sich zumindest nicht so massiv in Main an.

3. Auch eine autom. Registrierung würde bei Programmstart ablaufen. Theoretisch könnte später async was nachgeladen werden - doch ich glaube, das würde ein Wurzelproblem nur kaschieren.

Insofern kann die massive Registrierung als Feature denn als Bug gesehen werden: Wenn die Registrierung merklich lange dauert, ist das Programm schlicht zu groß. Siehe dazu meinen Blogartikel: http://blog.ralfw.de/2012/09/form-follows-feasibility.html

Ergo: Wenn die Registrierung der Operationen wirklich, wirklich ein Performanceproblem darstellt, dann melde dich und wir schauen nach der wahren Ursache. Bis dahin nimm Abstand von einer vorzeitigen Optimierung durch irgendwelche Tricks.

--
Ralf Westphal - One Man Think Tank
Hans-Henny-Jahnn-Weg 44
D-22085 Hamburg
Germany
Tel 0170-3200458
Email in...@ralfw.de

[petert]

So automatische Configuration hab ich schon mal auf Basis von Mef begonnen, leider aus Zeitgründen wirklich nur ein Ansatz...


http://npantarheicontrib.codeplex.com

[Andreas Schädler]

Hallo Ralf

vorerst vielen Dank für Deine Antwort.

Gerade erst habe ich mich nach langer Überwindung an die Schichten gewöhnt. Irgendwie hinke ich immer der Zeit hinterher :-)

Ok, mit den heutigen Mitteln könnte man relativ einfach von einem DB-Server zu einem Anderen wechseln ohne neuen Code zu schreiben. Ich erweitere eine bestehende Applikation WinForms basierend nun mit FD (oder versuche es zumindest) und hoffe, einmal alles umgestellt zu haben. Dabei achte ich, dass die Darstellung möglichst schlank und Komponentenmässig vom Rest abgetrennt ist, damit ich später mit wenig Aufwand die WinForms weg kriege. So denke ich in Schichten. Was änder da FD daran? 

Bezüglich Logik auf DataAdapter:

Habe mich wohl falsch ausgedrückt. Gemäss Flow-Design Cheat Sheet z.B. "Find customer by name" greift über "Customer repository" auf die Daten zu. Es ist für mich noch schwer, diese Verbindung auf die Platine, sorry, den Flow zu legen. Es ist so schön praktisch und verlockend, in "Find customer.." eine Funktion des Repository aufzurufen, welche die Daten liefert. Umdenken kann so umständlich sein.

Bezüglich der Instanzierung im Main:

Momentan verwende ich die Runtime noch nicht und arbeite eben mit EBC Platinen. Mit einer entsprechenden Basisklasse geht das relativ schlank und Lazy-Loading ist auch eingebaut. Aktuell habe ich also kein Problem. Deinen Artikel habe ich Anfang Woche mal überflogen. Werde ihn aus diesem Blickpunkt noch genauer ansehen. Kann mich, glaub ich, auch daran erinnern, dass Du schon früher mal etwas geschrieben hast, man soll in Apps denken und nicht in grossen Anwendungen. Habe mir einfach nur vorgestellt, wie das in einem ERP aussehen müsste. Ein Mainprogramm mit Menüpunkten zu Adressenen, Lieferscheien, Rechungen, Lager... 

Hoffe ich sprenge mit meinen Unsicherheiten den Rahmen dieser Gruppe nicht. Wenn es zu viel wird, sagt es.

Gruss

Andreas   

[Ralf Westphal]

Ok, mit den heutigen Mitteln könnte man relativ einfach von einem DB-Server zu einem Anderen wechseln ohne neuen Code zu schreiben.

aber es geht gar nicht darum, ohne neuen code auszukommen. es soll egal sein, ob das so ist oder nicht. schichten haben das auch immer schon gewollt.

 

Ich erweitere eine bestehende Applikation WinForms basierend nun mit FD (oder versuche es zumindest) und hoffe, einmal alles umgestellt zu haben. Dabei achte ich, dass die Darstellung möglichst schlank und Komponentenmässig vom Rest abgetrennt ist, damit ich später mit wenig Aufwand die WinForms weg kriege. So denke ich in Schichten. Was änder da FD daran? 

im schichtendenken stecken immer noch abhängigkeiten. eine obere schicht ist von einer unteren abhängig. das ist nicht gut. deshalb gibt es überhaupt flow design: um mit diesen abhängigkeiten aufzuräumen.

ansonsten hat CCD dazu eine meinung. darin gibt es aus gutem grund kein schichtenmodell. denn viel allgemeiner als schichten sind aspekte (oder responsibility oder concern).

 

Bezüglich Logik auf DataAdapter:

Habe mich wohl falsch ausgedrückt. Gemäss Flow-Design Cheat Sheet z.B. "Find customer by name" greift über "Customer repository" auf die Daten zu. Es ist für mich noch schwer, diese Verbindung auf die Platine, sorry, den Flow zu legen. Es ist so schön praktisch und verlockend, in "Find customer.." eine Funktion des Repository aufzurufen, welche die Daten liefert. Umdenken kann so umständlich sein.

im cheat sheet hab ich das mal als beispiel für eine mögliche abhängigkeit beschrieben. muss man aber so nicht machen. insb mit der flow runtime würd ich darüber länger nachdenken. denn wenn eine repo methode eine passende signatur hat, dann kann sie einfach in den flow gehängt werden. da muss man keine operation drumwickeln.

außerdem sollte das beispiel auch nicht darstellen, dass BL ein DAL aufruft. vielmehr stehen das repo und die find-operation in einer linie: es geht um persistenz. das wäre tatsächlich eine schichtung, wobei der begriff stratifizierung im sinne von abelson/sussman wohl besser wäre. es steigt ja das abstraktionsniveau.

 

Bezüglich der Instanzierung im Main:

Momentan verwende ich die Runtime noch nicht und arbeite eben mit EBC Platinen. Mit einer entsprechenden Basisklasse geht das relativ schlank und Lazy-Loading ist auch eingebaut. Aktuell habe ich also kein Problem. Deinen Artikel habe ich Anfang Woche mal überflogen. Werde ihn aus diesem Blickpunkt noch genauer ansehen. Kann mich, glaub ich, auch daran erinnern, dass Du schon früher mal etwas geschrieben hast, man soll in Apps denken und nicht in grossen Anwendungen. Habe mir einfach nur vorgestellt, wie das in einem ERP aussehen müsste. Ein Mainprogramm mit Menüpunkten zu Adressenen, Lieferscheien, Rechungen, Lager... 

schau dir das iphone an. da siehst du, wie das geht. alles zerfällt in vergleichsweise kleine apps. ob die mit einem ganz eigenen UI auftreten oder in einer shell zusammengefasst sind, ist egal. es geht um die grundsätzliche trennung.

im seminar "agile architektur" (http://www.sigs-datacom.de/seminare/seminardetails.html?tx_mwworkshops_pi1[showUid]=1540&tx_mwworkshops_pi1[dateID]=747) haben wir das neulich auch mal provokant praktisch ausprobiert: wir haben jeden handler für events im UI einer kleinen anwendung durch eine eigene EXE realisieren lassen. das waren die ganz getrennten apps. das hat laune gemacht und war ein aha-erlebnis für die teilnehmer.

 

Hoffe ich sprenge mit meinen Unsicherheiten den Rahmen dieser Gruppe nicht. Wenn es zu viel wird, sagt es.

Gruss

Andreas   

[Andreas Schädler]

Vielen Dank für die Ausführungen. Nun habe ich viel zu überlegen.