OOPhoto - Data Validation Layers And Night Club Bouncers

@Ben,

I would challenge your Wallet = View assumption. In your application, the decision about what data to share is actually handled by the User, and the same with your bouncer scenario: YOU decided to only hand over your ID rather than the whole wallet. The bouncer serves a dual role (we humans are so complex!):

* You are the User: you provide the input
* The bouncer demands "ID, please!" and holds out his hand, that's the View: it lets the User know what is expected and what will be accepted
* The bouncer is also the Controller: he expects an ID, not an entire wallet, and he passes the ID off (in his head) to the Model
* Management sets rules which function as the Model (18+, 21+, on the VIP list, etc): the Controller passes along the ID to the set of rules defined by management and gets a "go" / "no-go" back
* Based on the results of processing the ID vs the Model, the bouncer/Controller then returns the proper hand/View to the User: the hand goes up in your face = "FAIL!!" or the hand waves you in the door = "PARRTEEEE!"

The example is muddy because the bouncer/Controller also implements the business rules and the hand/View, and that's not good MVC, but humans can just process a lot more decision points than any ol' server can and we seamlessly integrate our I/O at the same time.

Not sure if that helps ... but I hope so.

-jfish

Hi Ben,

I've been trying to learn OO principles as well and have used a couple of the popular frameworks to date. Nice post!

I like the notion of the 5 line rule.... the procedural bones in my body go haywire VS such a rule!
;-)

@Ben,

Hmmmm. I like that illustration. I think, though, that the Controller in that situation does just send on the scan data mindlessly, doesn't it. I mean, the scanner literally just grabs data off the license bar, maybe ID + date of birth + name, whatever's on there, and it sends it to the model. The complexity of decision-making then, is completely on the model: maybe 1) check that date of birth = 21+ years old, else fail; if success, then 2) check that name is on the VIP list, else return "let him in"; if success, then "let him backstage". Now, if you have a Service separate from a DAO, the Service will know to parse out just the DoB for step 1 and just the name for step 2, and the DAO (or Gateway or whatever) simply processes the data request. Even the top of the model may never use the actual ID value, although it was sent. In either case, the Controller simply gets back a 'response'.

For example, in your PhotoGalleryService object, it knows to expect a string value when asked to GetGalleriesByKeyword(); even if you sent it 5 other args in addition, it's only going to use the Keyword value to process the request.

Just thinking out loud here ...

@Ben,

Aha, I see what you're talking about now. Still, though, in an application, doesn't the User do the entering? I still think the hand-held device is the Controller, regardless of who enters, I guess.

It's always this theoretical stuff that seems so much more complicated than the actual coding! LOL

With respect to the form issue and naming conventions, it seems to me that ColdFusion just can't do the OO things that would make this "jive".

The current strategy, as you know, is just to pass the form along and require that form ids = object properties = database columns. If you don't, you need to fatten your controller.

It seems that traditional OO languages would handle this differently, but they are not centric to "data processing". You are going to spend a whole lot of time and seemingly an extra layer if you try to sway from this current standard.

For instance, in every "learn OO" thing, the examples are applicable to real word things. Even your bouncer situation is a real world processing thing. I've never seen a good example of "pure" OO when it is specific to what we do, process, store, retreive, validate and display data. I've seen examples that are systems for doing the above, (i.e. coldfusion itself).

So, for us, it gets modified and that's ok. We bend the rules a little here and there because it just won't ever make sense without adding an extreme amount of complexity.

@Ben,

I would agree. I think the Controller isn't necessarily 'fat' simply because it knows to handle the translation of form['var1'] => method(arg1). If var1 is called 'firstName' in the form and 'userFirstName' in the first cfargument of the method, I don't see a problem with that. That's what it's controlling after all, isn't it? the flow of data between View and Model? Using separate Service and DAO layers as you are further encapsulates both the View and Controller from the database as well, further reducing the need for things to match up and down the line, IMO.

Clearly there are cross-over points that feel less than separate: such as having Validate() on the bean which the services are passing around and having very similar validation in the View, such as JavaScript, if you want enhanced user experience. But I think that illustrates the point that each piece of the puzzle certainly does have to know something of the overall app. It's never simply a matter of magically stitching together collections of entirely generic view, controller, and business objects and getting a recognizable result that meets a specific user need. Each element is part of the larger application, and as much as each area of concern needs to be stand-alone in the sense of handling all its own actions, each piece does have to 'know' its own role as well as how to interact with the other pieces it touches.

Just my 2c

@Ben,

Could not agree more. Just because much of the same validation is likely to happen in both the Model and the View does not mean that the Model should somehow push all the way up to the View. First of all, only the Controller should be pushing anything to either of them, and secondly, as you point out, the UI is responsible for handling the user experience, whatever that may need to be. We're on the same page that simply because it seems easier to put similar validation in one place ("View needs a username" and "Auth Bean needs a username") doesn't make it OO, and in fact that would rely on the Model speaking to the View, which definitely 'breaks' (whatever that means) MVC.

My point on the validation wasn't that the Model should push all that, it was simply that in your case you are going to have some apparent "code twice" situations, simply because you're doing both the Model and the View and they will seem to share some validation schemes. I entirely agree with you that they need to remain separate, and I think the result of that separation will naturally make the Controller a bit more than 5 lines simply because the Controller does have to know enough to translate between the View and Model, which is its job.

Still loving this OO journey, and learning to put some much finer and clearer points on my own OO design assumptions in the process. Thanks!

Are you sure that we aren't forced to bend the rules because of the nature of our applications. Afterall, we rely on a set of W3C standards, Browsers, and HTTP that has nothing to do with OO. ColdFusion doesn't even provide all the tools to produce "real" OO. Heck it's because of the browser that we are forced to run two separate, but similar validation.

For instance in the controller:

myBean = beanService.createBean(form);

myValidator = new Validator();

errorStruct = myValidator.validate(myBean.getValidationStructure);

//do stuff with errorstruct that displays on view

Validator has the ability to break down a custom structure ruleset. The "ruleset" structure comes from the bean that assemble this structure for the validator when the getValidationStructure() is called. The controller manages the errors from the validator.

The "ruleset" structure created by the bean for a validator object might be psuedocode:

//array of structures
[
{property="property1",
validType={minLen=5, maxLen=50, required=true},
customValidMessages={"Property 1 is too short",
"property1DisplayName is too long", "Property 1 is required"},
{property="property2",
propertyDisplayName="Property 2",
validType={required=true
//by default, no custom error messages are required
}
]

This is what jquery validate does on the client side.

However, this still requires that your view know about the model naming conventions.

@Justin,

Well, yes, the Model would need to use the same var names as the View, if we followed this convention in our Controller:

myBean = beanService.createBean(form);

But my preference is for the Controller to handle the communication:

myBean = beanService.createBean(
username=form["myUsernameField"],
password=form["myPasswordField"],
savePreferences=form["savePreferences"]
);

At that point, some vars may match (savePreferences) and others may not, but the View and Model never have to know the details of the other. My Controller for CF may handle this differently than my ActionScript Controller in Flex, even against the same Model; basically, I want to the Model to simply report what it knows, and the Controller to translate that into what the View will understand. The View may in turn apply the Controller messages in a completely different way than originally expected, but it knows what it's getting and that's all that matters. I don't want the Controller to tell my View that it has to report errors in JavaScript alert(), because the UI designer may decide to show/hide a nicely skinned hidden div instead; I simply want to tell the View, "hey, we have an error with mistmatched passwords" or something, and the View takes it from there.

At least that's how I see the separation of MVC working, whether it's CF or any other language.