boo posted on Friday, August 08, 2008
I'm looking to see how some of you folks out there that have been using CSLA for a while might handle things in the below:
We just got done with a fairly major upgrade to a brown-field application. The original application is extremely ERD driven and very GUI heavy because of it. We only updated maybe 30% of the system to CSLA - the rest is standard 4 layers architecture (GUI/Manager/DAL/DTO).
This paritcular upgrade added some functionality that wrapped up very nice and neatly into a CSLA BO that we could just attached to a DTO and do some 'clever' programming in DAL to get them to play nicely. Yes, ideally we would of like to rip out that DTO and put a BO in it's place - but this DTO is part of an explosion of classes resulting from the ERD design and would be a 3 month project in itself to change to CSLA.
So anyway, the BO has about 10 properties (started off with only 6 but you know how stable software is) and only 2 child BO. The messages are pretty standard for the most part (Friendly property name X must be set, Friendly property name X cannot exceed 50 characters, etc). But we the child BO properties have a XOR relationship - ideally it would of been nice for them to have a common base class, and looking back we could've done this better, but we're stuck with it now. So there's a message that fire's if the XOR returns false - either A is set and B is missing, or A and B are both set.
Here's where I run into problems.
- Roughly 1/3 of these properties are automatically set by the application in the manager level
- The way the GUI is set up it would be impossible for 'Property X' to be invalid because from the user's stand-point how are they going to choose something that doesn't come from the drop down list.
- The XOR, being a paritcular problem because from the user stand-point - how are they going to set both of those - they're on different pages and if you gone to one page you can't get to the other.
So the users have to sign off on the messages and bring these *problems* up. I explained that we 'need' these messages (i.e. these rules) so that if another developer comes along and screws something up we won't don't end up with errors in the system. The intermediate solution was to prefix these messages with 'A system error occurred:' but this is a hack and an ugly solution IMO.
My question to you folks out there is how do
you deal with situations like this. It seems like you almost need a mapping that allows you to override a business rule message with 'user specificied' messages.
