Comments on: Data Validation vs. Object Validation http://blog.alagad.com/2008/10/27/data-validation-vs-object-validation/ Web Development Task Force Sun, 05 Sep 2010 08:52:01 -0400 http://wordpress.org/?v=2.9.2 hourly 1 By: Jared Rypka-Hauer http://blog.alagad.com/2008/10/27/data-validation-vs-object-validation/comment-page-1/#comment-4003 Jared Rypka-Hauer Thu, 06 Nov 2008 00:00:00 +0000 #comment-4003 I personally think that it's foolish to allow bad data into your model, period. It's thinking like this that has allowed things like SQL injection attacks to proliferate in the first place, and just because there's minimal risk of an attack like that in this case doesn't mean that, somehow, the best practice changes. Seriously, the whole notion of allowing your controller to pass invalid data to your model escapes me. It doesn't even make sense. I personally think that it’s foolish to allow bad data into your model, period. It’s thinking like this that has allowed things like SQL injection attacks to proliferate in the first place, and just because there’s minimal risk of an attack like that in this case doesn’t mean that, somehow, the best practice changes.

Seriously, the whole notion of allowing your controller to pass invalid data to your model escapes me. It doesn’t even make sense.

]]> By: John Farrar http://blog.alagad.com/2008/10/27/data-validation-vs-object-validation/comment-page-1/#comment-4001 John Farrar Mon, 27 Oct 2008 00:00:00 +0000 #comment-4001 I get the point to your argument, but isn't it more abstract than applied? People may come up with one argument about where your thoughts apply and another would give a application where they feel it wouldn't apply. Note that I agree with your basic concept but that doesn't mean your complete concept is something that seems to be an absolute bad thing. It seems to be something that can work both ways but there are advantages to doing things before the business object. (With that said... it sure would be nice if we had a real object persistence vs persisting our objects via relational databases.) I get the point to your argument, but isn’t it more abstract than applied? People may come up with one argument about where your thoughts apply and another would give a application where they feel it wouldn’t apply. Note that I agree with your basic concept but that doesn’t mean your complete concept is something that seems to be an absolute bad thing. It seems to be something that can work both ways but there are advantages to doing things before the business object. (With that said… it sure would be nice if we had a real object persistence vs persisting our objects via relational databases.)

]]> By: Will Belden http://blog.alagad.com/2008/10/27/data-validation-vs-object-validation/comment-page-1/#comment-4002 Will Belden Mon, 27 Oct 2008 00:00:00 +0000 #comment-4002 In Transfer, assuming "bean" and "object" are the same for the moment, you're never supposed to alter the primary data bean, but rather clone() it first. This allows you to have an object that is dirty, but still allow you to use an object and all it's functions without modifying the "real" object. In Transfer, assuming “bean” and “object” are the same for the moment, you’re never supposed to alter the primary data bean, but rather clone() it first. This allows you to have an object that is dirty, but still allow you to use an object and all it’s functions without modifying the “real” object.

]]>