Still evaluating CSLA
Several years ago I wrote my own framework dedicated to web applications. In short: the use-case specific data structure and it's validations are defined in XML. The data (business objects) used internally is in XML (DOM) format (which was a bad idea). Pages are als defined in XML and are rendered to HTML/JavaScript using XSLT (slow).
Anyway, I wouldn't recommend building a framework when it's not your primary focus. Now I'm looking for a replacement and CSLA is still very promising. I don't necessarily focus on web applications; WinForms, WPF/Silverlight are also considered. Main focus is to provide a common structure to our various applications which allows us to easily switch developers between projects.
Of course, however, CSLA is missing functionality that I have now. Let's discuss some of it.
Web pages in our applications are usually quite dynamic. E.g. field B and C are only enabled when field A has a certain value and in that case B is also required. Besides 'enabled' the obvious alternatives readonly and visible are also possible. So, apart from validations, there are conditions to be evaluated. Before thinking about implementation however, I suppose we should consider whether these kind of conditions should be part of the GUI or part of the Business Object. Considering the fact that BOs are behaviour-centric, I think they could very well be part of the BO. I'm very interested in your thoughts on this one.
In that case validations would be objects consuming a condition object. It would add a severity and description to it. (still some problems with the shortcircuiting functionality though ;-)
Conditions should be 'bound' to the properties that are used for it's evaluation. At the moment validations are 'bound' to a single property. When several properties are needed (e.g. startdate < enddate) we have to write a dedicated RuleHandler within the BO and we must not forget to register the dependent property. I think we should specify all properties that a Rule depends on, on registration. That way the dependency is registered implicitly and the RuleHandler can be common because it can be called with the values of all the properties it depends on. Does this make sense, or did I overlook something?
The dependent properties (specified on registration) have thus become the arguments for the Rule/ConditionHandler. It would be nice if constant arguments could also be specified on registration. Although it would only help in not having to specify a dedicated RuleArgs class for that handler.
You should probably also consider whether a condition should be validated anyway. If one or more of the properties, it depends on , is not valid evaluation might be useless. Otherwise you would have to test the validity of the properties within the Rule/ConditionHandler. My current framework does not evaluate rules if any of the arguments is invalid. On registration, you can specify what result should be returned in such cases (true/false).
Conditions are likely to consist of several other conditions combined by and/or. It is of course possible to create a dedicated Rule/ConditionHandler that performs the combined condition evaluation but I think it would be more elegant if you could use a combination of basic common conditions (I < K) and (I > L). Thus an AndCondition and OrCondition are needed.
Conditions can be seen as a special class of expressions: expressions evaluating to bool. So, instead of only supporting conditions we could possibly support expressions. In our applications, those are used for conditional values. In the former example, for instance, we could specify that B should have a value calculated as 1.19 * E when it's not enabled. Thus we have a condition: (A != certain value) and an expression: 1.19 * E. Note that conditional values can also specify constant values.
What I've discussed so far are extensions to CSLA I would require for it to replace our current framework. I'm interested in knowing whether (part of) it could be considered as a useful part of CSLA or not. In the latter case I'll have to try it myself. In that case however any useful pointers, remarks, thoughts etc are more than welcome.
Even more challenging is how to make those conditions available to the GUI. Possibly extenders and/or decorators may come in handy. But that's for a later time...
There's a lot to think about there.
And there's a lot to balance. Backward compatibiilty, performance, behavioral support across all 7 or 8 interface technologies currently supported, etc.
Certainly I've learned a lot as I've implemented and enhanced the framework over the past few years. In a few cases there are things I'd do quite differently if I wasn't worried about backward compatibility, but while not a trump card, it is very important.
The idea of creating an AddRules() overload to allow association of a rule with multiple properties is not a bad idea. It is a little tricky, in that the RuleArgs is aware of the target property, so it would be more likely that it would be an AddRules() where you specify multiple RuleArg instances - and that would be a bit awkward I think.
It is more likely that I'll do what numerous people have requested, and create an attribute that describes a rule, so you can attribute your properties. That's still quite tricky when you consider aribtrary RuleArgs subclasses, but isn't quite as bad if you assume the use of DecoratedRuleArgs as a base class (so all arguments go into a dictionary).
My guess is that this would solve your problem too, because there'd also be a dependent property attribute - so the whole thing would become declarative.
(of course behind the scenes it just means that BusinessBase would reflect against all the properties, find these attributes and execute AddRule() and AddDependentRule() method calls - but still it would be nice)
I'm not entirely sure I understand the conditions stuff you are talking about.
It would be quite possible to create a rule that short-circuited processing if the target property wasn't valid. That's kind of what short-circuiting does already though, so I'm not sure it makes a lot of sense.
Put your cheap rules at priority 0 and the expensive ones at priority 1+ and if any cheap ones fail no expensive ones will run. That's the current behavior.
Of course this all gets a lot more complex in version 3.6, with the introduction of async rules. Well, actually the current behavior isn't more complex - it is unchanged. But async rules obviously can't short-circuit because they run in parallel, and typically after all sync rules are complete and the user has moved onto another field (in an interactive UI).
Thanks again. I always wonder where you find the time to react to almost every forum thread.
RockfordLhotka:
Certainly I've learned a lot as I've implemented and enhanced the framework over the past few years. In a few cases there are things I'd do quite differently if I wasn't worried about backward compatibility, but while not a trump card, it is very important.
I know the feeling; once you're done you know how it should have been done (and those two are always different ;-)
I'm not entirely sure I understand the conditions stuff you are talking about.
To me a rule consists of a condition that needs to be tested and (among others) a severity and an error message. When a condition is used to either Hide or Display some part of the GUI, the severity and error message are not needed. In fact, such a condition wouldn't have a target property either. That's why I also mentioned that making the condition result available to the GUI is something to think about.
Still want your opinion on whether these type of conditions considering the GUI should be inside the BO or not?
It would be quite possible to create a rule that short-circuited processing if the target property wasn't valid. That's kind of what short-circuiting does already though, so I'm not sure it makes a lot of sense.
My concern is not the target property (as a condition may not have one after all) but one of the dependent properties. If one of those is invalid, evaluation of the condition is useless. That would require repeating the validity checks of the dependent properties inside the RuleHandler which is unnecessary redundant. However, I still need a result to know whether the GUI part should by visible or not. That's why I suggested specifying a result for when the condition is not evaluated.
Skipping over everything else you wrote, this is the key point you really should be considering:
"web applications; WinForms, WPF/Silverlight are also considered. Main focus is to provide a common structure to our various applications which allows us to easily switch developers between projects. "
CSLA is just the ticket! It supports all of these environments withe the exact same set of BOs. That is pretty darn amazing!
I have some advanced Web screens which are completely generated based on metadata - so it shows 1 field to 1 type of user but hides the same field from 2 other types of users. The metadata is just another BO though. I also have lots of advanced business rules which are implemented in a very straightforward manner.
So don't let the very specific "minor flaws" stop you from implementing an overarching framework like CSLA which will solve your major problem.
Joe
Joe,
I know, that's why I'm still evaluating CSLA. There is too much functionality to throw it aside. Furthermore, I don't intend to write a complete framework myself anymore. I prefer an existing one like CSLA that can be extended where needed.
Copyright (c) Marimer LLC