ebcbinder v2 ??

Sep 30, 2010 at 1:45 PM

Hallo Ralf,

ich habe mich in den letzten Tagen endlich intensiver mit den EBCs beschäftigen können. Ich habe dafür mal eine der regelmäßigen Entwicklungsaufgaben mit Hilfe der EBCs simuliert.
Folgendes Szenario:
1. Ein Repository von Daten (z.B. User aus einer Db)
2. Eine Client-Application die mit diesem Repository "leben" muss um Daten zu verarbeiten.

Dabei ist mir aufgefallen, dass diese "Pinnerei" wirklich nervig wird, besonders wenn man Zwischenkomponenten wie Caching, Tracing, etc. einbauen will.
Also habe ich den EBCBinder losgelassen, der mir leider so nicht wirklich helfen konnte (Cache-Interception) und zusätzlich der Code mit der Naming-Convention von Pins sehr unübersichtlich wurde. 

Irgendwie wollte ich aber doch an einer Art EBCBinder festhalten, also habe ich deinen Code als Ausgangsbasis genommen und das ganze verändert, nun scheinen die mir bisher wichtigen Dinge zu gehen. Vielleicht ist das ja für V2 vom EBCBinder interessant, oder ich habe hier gar den EBCBinder V2 und es entsteht eine V3 :-)

1. Zu allererst habe ich mal ein PinNameAttribute eingefügt, welches sich auf die Pins anwenden lässt, damit ich im Quellcode folgendes tun kann.
[PinName("UserDataPin")]
var Action<> RequestUserData

[PinName("UserDataPin")]
void LoadUserData(...)

2. Habe ich im Binder das Intercepting mittels Action<> verworfen und durch eine Auflistung von Interception ersetzt.
Die Logik habe ich dahingehend verändert, dass eine Nachricht ausgehend vom OutputPin eines Pairs diese Interceptions der Reihe nach durchläuft. Dabei kann jede Interception diese Nachricht verändern, speichern oder sogar bestimmte Informationen des Pins (CustomAttributes) auslesen. Ferner kann eine Interception diesen Flow abbrechen und gegebenenfalls einen vorhanden InputPin direkt anspringen (Caching). So gesehen kann eine Interception also eine neue Leiterbahn auf der Platine ätzen um das Ziel schneller zu erreichen.

Das funktioniert auch jetzt endlich super, und ich kann z.B. einen Cache generisch zwischen die Pins klemmen (gut es gibt CacheAttribute um Ein-/Ausgang-/TargetPins zu deklarieren) und muss nicht mehr alles von Hand verdrahten, aber und das ist ein wenig das Haar in der Suppe: Die Interceptions (oder besser Intercepticons?) sind jetzt selbst keine EBCs mehr, wobei Sie das vielleicht auch nicht sein müssen...

Wie denkst Du (oder auch die Community) über diese Ergänzungen/Änderungen?
Gruß

Jul 1, 2011 at 7:13 AM

Hallo petat

 

das hört sich doch interessant an. Hast du noch bisschen daran weiter gearbeitet? Gibt es den Source Code deiner Änderungen irgendwo?

 

Gruß

Tobias