Vibrant discussion about CSLA .NET and using the framework to build great business applications.
Currently CSLA defines its own ValidationException class. Why can't it just use ValidationException defined in DataAnnotations' namespace?
Never say never and always avoid always
CSLA has existed for just a little longer than DataAnnotations (more than a decade longer actually). It had to do something for all those years before Microsoft finally realized that validation was important
Switching exception types is a breaking change. People use exception types in their catch blocks. So switching to use a new type of exception isn't the trivial thing it might seem at first glance, since it means that the thousands of CSLA users would have to go through their code to find and fix all those catch blocks.
That said, this didn't occur to me and would be a good idea for CSLA 4 - I'll have to see if I can squeeze this in - though technically the door has closed for adding new CSLA 4 changes.
Thanks for bringing this up!
I've put a little more thought into this. I'm not entirely sure it is a good idea.
There's a short-term pain issue - it is another breaking change from 3.x to 4 - but I could live with doing that.
The bigger problem is that it forces a dependency on System.ComponentModel.DataAnnotations for anyone using Csla.dll.
Right now, even in CSLA 4, you don't need to add a reference to DataAnnotations unless you decide to actually use the attributes it contains. It is completely optional.
But if I start raising ValidationException exceptions from DataAnnotations then anyone handling that exception type (which I suspect is most people) would need to reference DataAnnotations in their projects.
What does everyone think? Should I make this change? Do you explicitly handle ValidationException exceptions in your code?
I do not like the additional dependency. As I recall there was a huge backlash about this type of dependency in earlier work you did. For that reason alone I would not make the change. If DataAnnotation exception was in a standard .Net .dll that is always referenced anyway then I would be for it.
Is there any real advantage to switching, besides shaving that code out of CSLA?
No advantage I can see.
I think Csla should just keep its own exception. MS may take theirs in another direction at some point, plus why add a dependency for a single class that provides no other advantages?
I agree with Andy I think.
At first I was going to write that it seems DataAnnotations are the future and why not take advantage of it any way possible. But after reconsideration I think that, given there are no real direct advantages to the switch, that a large part of the value of a framework like CSLA has been the protection from MS changes. I think generally leveraging DataAnnotations for business rules is a great feature, but abandoning the traditional CSLA mechanism completely is perhaps "betting the farm" on Microsoft a bit too much.
Same thing that applies to RDO, ADO, Linq2Sql, EF, etc. etc.