I'm preparing to take my company's existing Order process currently used in a VB6 app and move all of the business rules & validation into .NET (CSLA). The objects I intend to create are meant to be used by a web service method that receives the order info from another system. The web service, however, does not need to provide any feedback to the caller. So it is essentially unattended at that point. The order info needs to be validated and then sent to our backend systems.
Thanks.
In general terms:
If you decide to use CSLA classes and validate these you must have a well defined error handling.
If you only have simple validation rules like MaxLength, Range and Required I would use WCFDataAnnotations to get the validation on the contract objects.
Thanks, Jonny. You mentioned "If you decide to use CSLA classes..." That makes it somewhat sound like perhaps I shouldn't use CSLA objects for this particular scenario? Did I read that correctly? Or does that statement only relate to what you said regarding having only simple validation rules? (There are lots of business rules in addition to validation rules that need to be applied, and while many are simply, many are not.)
Like any framework, CSLA provides a set of valuable behaviors/features. If you need them that's good, and if you don't need them then you might not need the framework.
The primary value of CSLA tends to be just a few things:
In a pure backend batch processing scenario some of these become relatively useless. In fact you could argue (depending on the specifics of the scenario) that only the clean separation of concerns and consistent coding pattern really matters - and you can impose that discipline without CSLA as long as you clearly define how to implement your code.
Thanks for the reminders and clarification. A consistent coding pattern has definitely been part of the reasoning. My company hasn't had one in the past ten years, unfortunately, and the recent introduction of CSLA to other projects has been super in this respect (as well as in other ways). But the other part of what you state is why I'm questioning to begin with.
There's one big factor we're considering - one that is generally frowned upon based on previous arguments I've read from you: reusability. I know reuse isn't the intention of CSLA and that, instead, the use-case should always drive object design. I totally buy that - it makes sense. But in this case, I'm not sure an Order object for a backend process can't also be used by a UI interface down the road...in either case, an order needs to have business and validation rules applied to it consistently. And that consistent processing is what we're trying to create now. Hopefully I'm not being naïve about this. Any further thoughts are welcomed.
An Order object for a backend process will almost certainly be entirely unlike an Order object to support an interactive user scenario. Those are extremely different scenarios and trying to support both with one object model will result in a poor UI and/or poor backend performance.
Good to consider...I have not gone far into requirements so I'll be able to bring this concern up with my team.
H,
I often find that in web services I use more of a format validation and not so much business validation as I do in a client scenario.
So I agree with the points that Rocky lists plus you can use DataAnnotation rules in both CSLA and Contract objects.
And if you need a richer validation then I would look at CSLA business objects but they would certainly be different than in a rich-client, f.ex no async rules.
I'm not saying that you shouldn't use CSLA. But it is a good reminder to go through what and why you use the framework.
Copyright (c) Marimer LLC