gwilliams@msn.com:
Also, i just noticed that i put in the wrong email address when creating my account... email address should be gregwilliams_@msn.com... how do i change this? i have had to create a few accounts due to not getting a response back regarding bad passwords???
Email me directly and I can try to sort this out.
Well... the first thing I'll say is that I certainly wouldn't say that "CSLA's Rule validation is not recommeded to run/implement a Business Process". And I'd bet that most other forum users would agree with that - after all, they're implementing/running business processes just fine.
Having said that, it may not be ideal for your business process.
The introduction of an external Business Rules Engine and "helper classes" are going to cause you issues, largely for the reasons listed. Externalizing the business rules either takes control away from your CSLA classes, or makes it rather cumbersome to integrate. Discussions surrounding a BRE have been had on the forum before, and I don't think we came to a very satisfactory conclusion - but one was made. So you might do a forum search to see if you can come up with anything.
Having said that, many of these questions are certainly answerable in CSLA. The "on hold" concept is doable, since I would presume that the status of your business objects changes when the call goes on hold. Your business rules can leverage that property when evaluating the object. I don't see that as an "inconsistency", since your business rules should be able to return the severity (warning/error) of the rule based on its current status.
I'm a little confused about the "we need more than a true/false" statement - a rule is either broken or it's not. So I'm wondering what kind of business rules "require questions and answers" that aren't of the true/false nature?
Along similar lines, the concept of "maintaining the broken rule collection when an invalid rule is overridden" is a problem whether you use CSLA's rules or not. If your system allows you to say "you know, this broken rule isn't really broken", then I say it's not really a broken (i.e. hard-and-fast) rule to begin with. CSLA's system allows for warning messages, which don't stop processing, and are probably a better fit for this kind of situation.
In terms of launching the validation rules, they are correct - repeatedly setting property values is inefficient, and exposing the validation methods as publicly-callable is technically no better than creating methods to call the BRE directly. And that's part of the point - if your business rules are external to your business object, the "real-time validation" concept of CSLA pretty much doesn't apply anymore. It's much more of a web-style scenario, where you're filling out forms, pressing the "Submit" button, and seeing what breaks. That's certainly a model that's supported in CSLA, but you're not going to see anything that's significantly better than directly calling your BRE when you need to.
And as for the redundant calls to the BRE when saving, you can always override the Save() method and do your own thing. I wouldn't necessarily recommend it - what you might call "redundant" I call "a fail-safe against programmers forgetting to call the BRE". ![Smile [:)]](/emoticons/emotion-1.gif)
I would also argue that CSLA's validation-rule system is much more than just "validat[ing] simple property information like field length, format and other meta information of the property". It may be tied to properties, but the validation rules are ultimately just method calls - you can do pretty much anything you want. You are also not restricted to what's supplied in CSLA - you can write your own. So if your team is suggesting the validation subsystem is simplistic, then I think they need to take a step back and re-evaluate the framework.
Lastly, it's been recognized several times recently that "validation rules" was probably a poor naming choice, and I believe Rocky is planning on doing some rather major overhaul-type work in CSLA 4.0 on the whole business-rules section - including renaming it to "business rules". There's nothing wrong with writing "validation rules" that do nothing more than data transformation, or other non-rule-type processing. It's actually become rather common - thus the discussion of the unfortunate name.
HTH
- Scott
tmg4340:
Having said that, many of these questions are certainly answerable in CSLA. The "on hold" concept is doable, since I would presume that the status of your business objects changes when the call goes on hold. Your business rules can leverage that property when evaluating the object. I don't see that as an "inconsistency", since your business rules should be able to return the severity (warning/error) of the rule based on its current status.
Also, it may be there's a CallInProgress BO, which validation rules are always warnings and thus savable, and a seperate CallComplete BO, which changes a call from in progress to complete. This BO would have validation errors preventing it from saving (which would move the call from InProgress to Complete).
tmg4340:I'm a little confused about the "we need more than a true/false" statement - a rule is either broken or it's not. So I'm wondering what kind of business rules "require questions and answers" that aren't of the true/false nature?
This sounds very much like a bad design being the culprit. Instead of a question and answer, and the behaviors which go along with it being a Csla businessbase subtype, they're trying to stuff that into a single method. Their "rules" are corrisponding to methods when they should be a full blown BO, and a BO to them is nothing more than a collection of rule methods (which they want to alter dynamically).
tmg4340:I would also argue that CSLA's validation-rule system is much more than just "validat[ing] simple property information like field length, format and other meta information of the property". It may be tied to properties, but the validation rules are ultimately just method calls - you can do pretty much anything you want. You are also not restricted to what's supplied in CSLA - you can write your own. So if your team is suggesting the validation subsystem is simplistic, then I think they need to take a step back and re-evaluate the framework.
I think there's a deep misunderstanding of what Csla is meant to do, and how they would effectively use it. It sounds like the offshore team is trying to look at the framework's code, without understanding its design goals and purpose, and shoehorn in their BRE, not knowing Csla objects are supposed to enforce the rules.. Kinda like picking Linq2Sql then blaming it when you can't connect to an Oracle database..
It is important to properly design your objects too. Remember that a good object design follows the use case (user scenario) not the database design.
So if you have a multi-step process, for example, you may have different objects for different steps. That is a type of rule, but it is embedded in the shape of the object graph, not as an explicit rule. The same is true for parent-child relationships - those are a type of rule, but that rule is intrinsically part of the object graph.
It is also the case that you can use severities. If many/most of your rules are warnings, then make them warnings. Windows Forms ErrorProvider can't help you there, but the WPF/SL PropertyStatus control is good, and there are CslaContrib controls for Windows Forms. Web Forms or MVC can display whatever you want to render, so a warning is no different from an error in terms of work effort for that UI style.
Remember that a rule sets the severity, so it can choose warning or error depending on the state of the object graph.
Finally, you can use priorities and short-circuiting. People often underestimate the capability of this feature, but it can be used to do some pretty amazing things, including making sure that some rules never run at all until the object state reaches some point where those rules make sense. Of course those rules could directly implement such a check too - but you can use e.StopProcessing to achieve a similar result.
Copyright (c) Marimer LLC