IWETHEY v. 0.3.0 | TODO
1,095 registered users | 2 active users | 2 LpH | Statistics
Login | Create New User
IWETHEY Banner

Welcome to IWETHEY!

New That's just the command object.
Basically it turns the form fields into a command for the controller to process. The validator confirms that the command is valid. The trick is this: if the command isn't valid, then it gets used as the form backing object again. This gives you persistence between form invocations so the user doesn't simply get a blank form again.

A different kind of form that edits or creates a new object (like a user registration or edit form) would just use the business object that it's creating/editing. The Spring tutorial example is a bit wierd in the respect that they've chosen to demonstrate a true command as opposed to the Create/Update sort of thing you see more often.
Regards,

-scott anderson

"Welcome to Rivendell, Mr. Anderson..."
New So is PriceIncrease.java part of model, view or controller?
I'm stil thinking that the ProductManager class should have its own validation. Or is part of MVC that the models should not contain the validation? I can understand different interfaces having different validation rules -- possibly based on user access, on local vs. remote access, on real-time vs batch processing, etc. But to have all the validation in what feels to me like a middle tier doesn't seem right.
===

Purveyor of Doc Hope's [link|http://DocHope.com|fresh-baked dog biscuits and pet treats].
[link|http://DocHope.com|http://DocHope.com]
New The reason for the validators
Let's say you have a business class that can get loaded from the database or from form input. You don't want the validation to occur on database load. Or you might have logic in the validation that does things to the business object based on other input, and you don't want that happening at database load either.

A real life example: we have a user bridging application that loads the user (if it exists) from the database, then overwrites that default data with anything that may be sent from the form POST. There's a lot of validation that gets applied to the form POST data (such as defaulting a field if another one isn't present, etc) that shouldn't be applied if the data is loaded from the database.

Another example would be a wizard interface, where you only want part of the validation applied incrementally at each step.

There are other ways to do this, such as a subclass that applies the validation, but you only get one subclass in Java. Validators abstract the validation step out (as a Strategy pattern, if you're into that sort of thing) out the business object so you can pick which validation strategy you need at any point in time.
Regards,

-scott anderson

"Welcome to Rivendell, Mr. Anderson..."
New Okay, we don't typically do that
That's more of an OR layer between the apps and the db. Our objects typically depend on a unique identifier being passed in to the constructor. If the object doesn't alreayd exist (in the db) the app first has to call a static method in a separate library file to create the record in the db and return the id. Then the id can be used to create the object.

We've got a bad history of badly-written classes that can be used both for pre-existing records and for creating new ones. To start using the business objects as an OR layer would require cleaning up a lot more code first. Like the fact that probably over half our pages still have direct db access. I'd like to fix that mess before worring about an OR layer.
===

Purveyor of Doc Hope's [link|http://DocHope.com|fresh-baked dog biscuits and pet treats].
[link|http://DocHope.com|http://DocHope.com]
New It's not an OR layer.
How the class gets loaded from the database is immaterial. The validation is separate from that load, which is entirely the point.
Regards,

-scott anderson

"Welcome to Rivendell, Mr. Anderson..."
New Not what you said / I heard
You said the data may come from the db, or it may come from somewhere else. I was about to say that if the data didn't come out of the db then it must be a new record, until I remembered a report I did where there's a single select to get all the data. For each row of the results I create an object by passing in all the data, so that I can then use the output formatting methods of the object.

Hmm, I've been preaching lately that our object constructors should be more lightweight, only hitting the db as much as we need to for the current operation. (Our worst case is an object that has at least six different init methods depending on which data you're working with, and someone decided it would be easier to just call all of them in the constructor.)
===

Purveyor of Doc Hope's [link|http://DocHope.com|fresh-baked dog biscuits and pet treats].
[link|http://DocHope.com|http://DocHope.com]
New You missed one.
It could come from the database for display, it could come from a "new item" form, or it could come from an edit form.
Regards,

-scott anderson

"Welcome to Rivendell, Mr. Anderson..."
     Question on the java Spring tutorial - (drewk) - (7)
         That's just the command object. - (admin) - (6)
             So is PriceIncrease.java part of model, view or controller? - (drewk) - (5)
                 The reason for the validators - (admin) - (4)
                     Okay, we don't typically do that - (drewk) - (3)
                         It's not an OR layer. - (admin) - (2)
                             Not what you said / I heard - (drewk) - (1)
                                 You missed one. - (admin)

Clearly designed to be used by faery maidens with a feather touch, rather than a six foot three engineer in a pair of size 13 steelies.
49 ms