|
Common Components SDK v1.6.0 can now be downloaded from our website. This version has a minor improvement to the graph-building feature-set and a new feature-set we call "ordered roles."
Enhanced Graph Building:
We now support graph-node-builders which do not, themselves, build anything but delegate to other builders. An example
of where you might use this feature would be when your builder has to choose at the last second which of two builders is the
right one. GraphNodeStagingPoint now has a ForwardTo method which accepts another graph-node-builder. For all intents and
purposes: this merges the current graph node staging point with a new one, associated with the correct builder.
Role Odering:
One of the more powerful concepts in this framwork is that of the composite object processor. This is, more or less, a
pretty generic way of expressing either a Chain of Responsibility, or a Decorator (depending on which variant you use).
While their interfaces aren't quite as intuitive as "home grown" implementation of said patterns, we have found the
ability to write generic clients which manipulate CoRs and Decorator chains to be an overpowering advantage. That and
you can always encapsulate...
The primary measurement of this advantage is flexbility... the ability to fairly intelligently merge sets of rules into
a cluster of objects which behaves as though it is just another variant in some Strategy pattern. The key, however,
is that "fairly intelligently" part. We found ourselves using the same set of... meta rules?... to control how bundles
of rules were merged together into a single object processor. Those "meta rules" are what this new feature-set encapsulates.
Take a look at the Ordered Role Set and friends. These objects let you reliably build ordered lists of roles while only
specifying the minimum amount of information necessary. More importantly: you only have to make those specifications where
they matter. Whereas, in the past, we might have made some kludge to manage this - priority numbers, some overly complex
network of relationships, or whatever - with the ordered role set, we have a very simple solution...
We declare a number of "buckets" (roles). Every rule goes into one bucket. If you are writing rules that fulfill more than
one role, you probably shoul not be using this framework. Each rule, then, declares not only the role it fills, but the roles
it precedes and succeeds. The result is an extremely flexible mechanism for specifying how rules work together. The rules
which are born with the most knowledge (the ones born most recently) an use that knowledge to exhert the greatest amount of
influence over the workflow in which they reside.
FREE:
Common Components is still completely FREE.
Related Links:
Download
|