Exceptional Exception Handling
I have a response to Jeremy's rant...
I'll admit up front that I'm an infant when it comes to agile/domain-driven design stuff, but this is something that a coworker and I have debated for sometime now. Long story short, the application he's migrating to .NET (and NHibernate, DDD, etc.) uses exceptions within the domain object property setters to send back validation error messages to the user. The exceptions themselves don't make it to the ASPX, but are still used as the "delivery" mechanism.
So, for example, if a Person's FirstName is required and cannot be longer than 50 characters, the setter would throw an ArgumentNullException or ArgumentOutOfRangeException respectively. Somewhere in the MVC layer of the application (I think the Controller, but I'm not sure), all exceptions are caught, translated (so an ArgNullEx will be translated to "FirstName is required") and the error messages are displayed to the user. He also added some attributes to help the MVC layer detect which data members are required, have length requirements for strings, etc. Since NHibernate is not able to discover this information from the database - at least, not that we've found.
Personally, I'm at a stalemate on the whole design. While it is intuitive and follows the DRY (Don't Repeat Yourself) pragmatic principle - to a degree, since there's duplication in the mappings and the database - and is centralized in the Controllers, any View implementation will automatically "enlist"(?) for validation. On the other hand, I feel this is breaking the idea of "Separation of Concerns"; I'm not sure if it's the Controller's responsibility to validate the data that's being marshaled to/from the Model or, for that matter, if the Model should be concerned with performing the actual validation. Is the Model just a plain-old data structure with no logic? There's also the design consideration I've read a few times around stating "save exceptions for exceptional cases/conditions"; does data validation fall under that umbrella?
Less "annoying" is the fact that we're (I really mean he, I just consult...and I "[have] been known to be wrong...from time-to-time") not using any of the ASP.NET validation controls as they can be cumbersome when there's the idea of separate logical forms and such...but that's really minor, when you get down to it...
Anyway, those are my thoughts. To surmise: where DOES validation logic belong? Obviously, it is easier to maintain in the higher-level languages...but where in your app's architecture does it really belong??
I'll admit up front that I'm an infant when it comes to agile/domain-driven design stuff, but this is something that a coworker and I have debated for sometime now. Long story short, the application he's migrating to .NET (and NHibernate, DDD, etc.) uses exceptions within the domain object property setters to send back validation error messages to the user. The exceptions themselves don't make it to the ASPX, but are still used as the "delivery" mechanism.
So, for example, if a Person's FirstName is required and cannot be longer than 50 characters, the setter would throw an ArgumentNullException or ArgumentOutOfRangeException respectively. Somewhere in the MVC layer of the application (I think the Controller, but I'm not sure), all exceptions are caught, translated (so an ArgNullEx will be translated to "FirstName is required") and the error messages are displayed to the user. He also added some attributes to help the MVC layer detect which data members are required, have length requirements for strings, etc. Since NHibernate is not able to discover this information from the database - at least, not that we've found.
Personally, I'm at a stalemate on the whole design. While it is intuitive and follows the DRY (Don't Repeat Yourself) pragmatic principle - to a degree, since there's duplication in the mappings and the database - and is centralized in the Controllers, any View implementation will automatically "enlist"(?) for validation. On the other hand, I feel this is breaking the idea of "Separation of Concerns"; I'm not sure if it's the Controller's responsibility to validate the data that's being marshaled to/from the Model or, for that matter, if the Model should be concerned with performing the actual validation. Is the Model just a plain-old data structure with no logic? There's also the design consideration I've read a few times around stating "save exceptions for exceptional cases/conditions"; does data validation fall under that umbrella?
Less "annoying" is the fact that we're (I really mean he, I just consult...and I "[have] been known to be wrong...from time-to-time") not using any of the ASP.NET validation controls as they can be cumbersome when there's the idea of separate logical forms and such...but that's really minor, when you get down to it...
Anyway, those are my thoughts. To surmise: where DOES validation logic belong? Obviously, it is easier to maintain in the higher-level languages...but where in your app's architecture does it really belong??
posted by Harris at
5:59 PM
0 Comments:
Post a Comment
<< Home