I am sure this has probably been discussed to death in the Rails circles, but since I am not in those circles, I thought I'd ask for some clarification. Why did Rails place validation within the Model objects rather than in the Controller?
Gregg - I do not know 'why'. It will be interesting to see who chimes in with what further input.
Validation can be invoked anywhere you have a model object available, e.g.:
You can certainly use valid? in a Controller.
I use ActiveRecord in 'batch' (command line, outside of Rails). I suppose I could look at this in an MVC light, but tend not to think of the design like that. It does seem very convenient to have the validation infrastructure available.
Originally posted by Gregg Bolinger: Why did Rails place validation within the Model objects rather than in the Controller?
I'm not the original author of Rails but here's why I think they might've done what they did.
Putting the validation logic into the controller would violate object-oriented design principles of putting logic where the data is. In the case of validation, the data is the model object's fields and logic that revolves around that data should reside in the model object. In other words, the concept of "valid" should be embedded into your domain model rather than being mixed into your application logic.
Originally posted by Lasse Koskela: I'm not the original author of Rails but here's why I think they might've done what they did.
Putting the validation logic into the controller would violate object-oriented design principles of putting logic where the data is. In the case of validation, the data is the model object's fields and logic that revolves around that data should reside in the model object. In other words, the concept of "valid" should be embedded into your domain model rather than being mixed into your application logic.
That makes sense Lasse, thanks. My only argument against this (which might also be why a lot of JEE Frameworks don't follow this pattern) is that you tie your domain objects into a specific framework.
Now, before you scream and yell, I do realize that Rails is all we are talking about here. So there isn't a valid concern. You use rails, you are tied into Rails and there really isn't another framework you would want to port your model objects to, well...
From java's perspective though, it seems it might be difficult to follow this design. For example, if I were to put validation logic in my domain objects when developing an application using Stripes, then my domain objects have Stripes specific code (annotations). If I were ever to move my domain objects to a different framework for whatever reason I would need to remove and/or replace this logic with another framework's specific form of validation. I believe this is why we usually find validation in JEE apps either in the controller itself (Stripes) or separated completely and handled by the controller (struts). And then there is always the odd case of putting validation in the JSP (JSF). Ugh!
Originally posted by Lasse Koskela: I think I agree with what you said about coupling your domain objects to the framework in the context of some specific web frameworks.
However, I don't know that it cannot be done without such coupling.
I believe there is a JSR that has something to do with a standardized validation mechanism that frameworks would take advantage of. Something like Hibernate Validate but in the CORE JRE and/or JEE. I'll see if I can dig it up.