Interfaces as formal contracts are not missing from EBC. Right to the contrary! You can still define the offerings of an EBC component like your DataAccessComponent using an interface. And that´s even better than with IBC. Because in order to specify an IBC completely (like your BusinessClient) you´d need to list all exported interfaces as well as all imported interfaces. In your case that would be IBusinessClient + IDataAccessComponent.

In the EBC world the specification of the BusinessClient component would be just IBusinessClient.

I deem this an advantage over IBC. Specifications are more compact.

You´re right in that the current bindings are a bit cumbersome. EBC surely would benefit from generating them from some DSL.

However I find in my daily EBC practise that this drawback is only minimal compared to what is gained from EBC.

a) EBC “require” you to clearly separate domain functionality from code that just composes such functionality. It is a very helpful separation of concerns.

b) The difficult to read binding code usually is not very long. Due to the ease with which you can design on different levels of abstractions (compared to IBC) EBC boards are kept quite small.
In addition it is recommended to keep the design sketches with your code. They are a “poor mans DSL” until there is a designer tool. If you do that look at them to understand your software, not the wiring code in the boards. It´s a common mistake to stay glued to the code instead of using diagrams. With UML I understand why people do that; diagrams and code quickly get out of sync because it´s hard to translate from diagram into code. But that´s different with EBC. The translation is trivial. Thus the code is in sync with the diagram. And changes should flow from the diagram/design to the code.

So EBC fosters a less ad hoc, less cowboy programmer way of software development. Look at the cumbersome wiring code as a feature instead of a bug It´s a constant reminder to program in a clean way. Yes, that takes some getting used to it… but my experience is that´s worthwhile.

c) Although the wiring code is kinda hard to read it in fact is simple. It´s so regular… Once you develop an eye for it, it´s not that hard to comprehend anymore. I deem this simplicity very important. It makes software more predictable in its form. And that helps evolving it.

d) EBC very explicitly deal with dependencies. The only dependencies left are concentrated in board. And these board don´t have any domain functionality on them. So highly dependent code is simple. And complicated code is independent. That´s in accordance with all good principles of software development. Dependencies are the developers bane – penning them up in a few places thus is a great help.

Finally one word about topological dependencies as I termed them: They make IBC dependent on how functionality is grouped. If component C needs functions f() and g() it´s dependent on them. Maybe that cannot be avoided. But why in all the world should C also be dependent on f() and g() being lumped together on an interface?

As long as that´s the case C has two reasons to change (which is against the SRP): it needs to change if new domain requirements come up regarding its domain responsibility; and it needs to change if f() and g() are rearranged onto different interfaces for whatever reason. That´s bad.

-Ralf

PS: I suggest all interested in EBC to have a look at EBC 2.0. It´s a whole different view on how to carve out components from requirements. And the beauty of it: the nasty request/response communication simply goes away…

PPS: Just for the record: I´m not advovating giving up IBC altogether! Even EBC rely on them for defining EBC boards. But also beyond that IBC are of value. Don´t try to throw them away. They can be of great use within EBC parts/actions (atomic EBC components).

Regards
Gope

If I just delete all the “where TMessage : IMessage” statements, everything works just as well, but now I can do things like

var broker = new EventBroker();

using (var subscription = broker.Subscribe(s => Console.WriteLine(s)))
{
broker.Publish(“Hello!”);
broker.Publish(“World!”);
}

broker.Publish(“just kidding…”);

Currently I’m not sure if I would like this (while I like Rx). Can you show a concrete example of the usage?

http://enumeratethis.com/2010/08/27/latch-design-pattern-in-rx/

I totally agree to the lag of overview:
We are using the image of electronic circuits, which includes the components (== classes), the output-pins (== events) and the input-pins (== methods). The solder would be the EBC binder.

But we are still missing a circuit board! It would give us an overview of the connected (or faulty connected) pins. I’m thinking of a designer like the one for the Windows Workflow foundation… This could be the missed tool.

I’m going to watch the progress of EBC. Let’s see if it can join the club of the standard design patterns.

Thanks for your comments.

@AJ: thanks for clarification. Now I’m searching for a new name… Any suggestions?

@James: thanks for your alternative implementation. But I still prefer the initial code. The get/set of the property value is a responsibility of the PropertyMemento class, so I prefer not to provide these actions from the outside.

Another thing I’m currently not really happy with is the implicit nature of the using() syntax. It’s not very intention revealing. I think I will make another blog post on this during the next week.

Again, thanks for your input!

private PropertyMemento GetAutoSizeMemento(
Control control, bool tempValue)
{
return new PropertyMemento(
control,
() => control.AutoSize,
value => control.AutoSize = value,
tempValue);
}

Then we can reduce the definition of PropertyMemento to just this:

public class PropertyMemento : IDisposable
where TClass : class
{
private readonly TProperty _originalPropertyValue;
private readonly TClass _classInstance;
private readonly Func _propertyGetter;
private readonly Action _propertySetter;

public PropertyMemento(TClass classInstance,
Func propertyGetter,
Action propertySetter)
{
_classInstance = classInstance;
_propertyGetter = propertyGetter;
_propertySetter = propertySetter;
_originalPropertyValue = _propertyGetter();
}

public PropertyMemento(TClass memberObject,
Func propertyGetter,
Action propertySetter,
TProperty tempValue)
: this(memberObject, propertyGetter, propertySetter)
{
_propertySetter(tempValue);
}

public void Dispose()
{
_propertySetter(_originalPropertyValue);
}
}

and complete elininate the need for ReflectionHelper (and reflection in general)

I do have my doubts about the justification of calling this a “property memento”, though. Your citation of the Memento pattern cuts a little short (and wikipedia even got the definition of “opaque” wrong ); the GoF-Definition is somewhat better:

“Intent: Without violating encapsulation, capture and externalize an object’s internal state so that the object can be restored to this state later.”
http://www.c2.com/cgi/wiki?MementoPattern

My concern is that the Memento pattern clearly favors a black box approach for the object. Saving and restoring some property values on the other hand is equaly clearly a white box approach, as you need to be aware of any side effects between save and restore. And the value of a property is _not_ akin to the state of an object. It provides merely a representation (glimps, reflection, if you like) of a certain aspect of the internal state of the surrounding object.

Very theoretical mussings, I know. But that’s what you asked for

Again: I won’t disqualify your approach per se, it’s probably even more simple and efficient than a true Memento. I just wouldn’t call it “Memento”.