OOPhoto - No More Validation In The Controller

Thank you, Ben.

What would your approach be to multiple types of errors for one field? i.e. missing vs. too short? Additional struct keys?

@Ben,

I meant the various error message translation for the error type. I saw the different error validations. I was just curious what you :would: do, not that you should do it. :)

Not that I've ever actually done it this way :-) but my ideal approach (if I'm understanding the question correctly) would be to do the validation in the database, using a stored procedure to produce an error code (including a code for 'no error'). That code could be looked up in an 'error_message' table and the stored procedure could return it to the program. Again, I haven't actually ever done this (like you, I do only gross error-checking as I assume the users will generally put in reasonable values) - but that's how I've always thought "I really should do it this way..."

Matt

@Ben,

Doesn't the approach you outlined already account for multiple types of errors? If the value of a given key is InvalidValue you can construct a different message in the Controller than if the key is InvalidLength, right? You could simply choose to pass along:

If Error on Comment, then show "Please enter a valid comment."

But you could make the error handler smarter, too, if you wanted, since you already have the details from the Model:

If Error on Password, then
If Error is InvalidLength, then show "Please use an 8-character pwd"
Else If Error is InvalidValue, then show "Please use at least one number in your pwd"
Else If Error is Required, then show "Please enter your password"
/If

Or, frankly, you could pass the Error value along to the View, too, and let the View decide how (or if) to describe the details.

Seems like the pieces are there, and now it's up to the View implementation as to how / if to utilize what's coming back from the Controller, which is just what you want. And meanwhile you've already assured that at least the Model won't persist anything it shouldn't.

Nice work again Ben. Keep it up.

I'm personally hoping for a nice PDF of this entire series with comments included, to be my new most favored reference/guide. :-)

One drawback I can see to using stored proc validation is that you have to make absolutely sure that you'll be able to port the procs to a new DBMS if that's necessary. It does however give you a great deal of flexibility as far as adding new error types, changing messages, etc.

Can you tell I was a DBA in a previous life? :-) That's been my biggest challenge in approaching OOP - it's really hard for me to disentangle myself from a relational view of objects. (And don't even start with ORM, that's a whole 'nother mess. One thing at a time.)

Matt

I second the PDF suggestion. This is a great series thus far.

Ben, is there a reason why you want to perform the validation in the Service, rather than creating a dedicated validation object or set of validation objects, compose them into the business objects, and let the business objects handle their own validation?

Hi Ben, I get that certain validations may depend on calls to the service class, but I'm with Brian. Going back to the Single Responsibility Principle, I'd look at having a validation object composed within the bean. It will indeed need to have access to the service class for any validations across the universe of functions, but as your service classes do more and you have more different validation methods I think you're going to end up with a lot of methods within your service classes.

That said, the whole purpose of the experiment is to try things and play with different approaches, so keep on keeping on and see whether you run into any issues as the app gets more complex.

Ben,

I reckon you were on to something when you were talking about layers of validation. Some discussions about which object is responsible for validation run into trouble because we try to find one correct place, and/or feel bad if we end up with validation in more than one place. "Validation" is a single concept, so we should have a single coherent object to handle it, right? Wrong.

I don't have the definitive list of layers, but here's a start.

1. Absolute basic invariants. Your data simply can't make any sense if these are violated. Maybe your inserts and updates will just fail. This stuff should be defined at the database level where possible, *and* in the domain model beans. This has nothing to do with any controller or service, and it is completely legitimate to report validation errors simply by throwing an exception.

2. Uniqueness/consistency constraints. These are probably also defined in the database, but can't be coded into the domain model beans because they typically involve lots of domain objects. Normally I would code these into collection classes that are included in the domain model, as uniqueness is always defined relative to a specific collection.

3. Context-specific constraints. Finally we get to the controller layer. Rather than validating data, we are validating a command. Is it OK to delete this user record? Can I make this user a manager of this organisational unit? You can see this as data validation, but the command paradigm can be more useful. Security rules and differing application contexts can often boil down to making specific commands available or unavailable.

4. Input constraints. Ideally our UI doesn't let us submit invalid data. The truth is, though, that our UI layer can't always know enough to guarantee submitted data can be committed. So UI level validation (and in that I include both browser and server-side form validation) is really just initial data scrubbing.

One of the big headaches is doing all of this DRYly, particularly rules that have to be the same in both #1 and #4. I'm not sure if in general there actually is a way to stay DRY that doesn't breach encapsulation.

The rules in #1 are totally dependent on the actual data representation - e.g. database field lengths and types. The UI layer, which administers #4, has no business knowing any of that stuff. In a simple CRUD application we're quite justified in simply dropping encapsulation and tightly binding the UI into the data model, but more generally I think the price of encapsulation is going to be some duplication.

@Ben,

>When you refer to a "collection class", is that akin to my "service" >classes?

Yeah, probably. While conceptually a collection can be a first-class domain object, in practical CF the service layer can be a good place for this logic to live. Most people would be managing several collections from within a given service class, but I know Peter Bell has the concept of domain classes each having a paired service class (so he'd have User and UserService, Order and OrderService), and in a lot of ways those things are like collection objects.

>while I agree that #4 can exist, I don't think that it should really be >taken into account for THIS project

Fair enough. Most real-world applications will do some flattening and combining of layers, and some layers are simply empty for certain applications.

It's a common approach to try to handle security in the controller, but I would argue that it is actually a very bad place for it. Consider a Flex application or a web service making calls to this model. The HTML UI controller is not involved. The security enforcement needs to be handled in the model in order for this to be scalable across multiple types of access.

Unfortunately, this usually can get complicated. The best solution I've found involves AOP, since security is a perfect example of a cross-cutting concern, which is exactly the kind of problem AOP solves. However, it definitely adds another level of complexity. Even so, it beats the heck out of scattering security logic all over your service layer.

It may not be something you want to grapple with just now, but be aware that this will probably come up at some point. Yes, the cascade of things to learn never stops, does it? ;-)

@Brian,

Good point. Command objects (if one is using that style) would be invoked by the controller, but the controller should actually get those objects from the service layer (or directly from the model if the service layer is vanishingly thin).

Jaime

@Ben

I believe the issue that Peter is hinting at is that if you have a service that works on multiple object types, then now you need multiple validation methods, one for each type.

Of course provided you created separate services to map against each domain type, in addition to a "complex type" service that's not really an issue.

I don't really see any big issues with providing validation like this in the service in a small app like this. You're not gaining all that much by creating more cfcomponents that do validation, except a false sense of better abstraction. Now if you wanted to do some kind of automated validation based on metadata from the database and other complex logic you might benefit from a dedicated Validation Service just because it keeps your code more brief in the objects. Of course you could just extend some kind of object, or even mixin the methods for validation too.

More classes != better abstraction or better code.

Allowing an object to have knowledge of it's own validation semantics isn't breaking rules either. You could put all this validation down in the object itself and inject the services/components required for it. Some would argue this breaks some kind of abstraction, but there's hardly a rule against it.

Rails for instance has a method validate, validate_on_create and validate_on_update which are automatically invoked on those events. Or you can call valid? to do it yourself. Then every object has an "errors" property that contains the collection of potential errors.

<http://api.rubyonrails.org/classes/ActiveRecord/Validations.html>

Django takes a radically different approach to even that. Objects validate that they're sane, but you don't generally go at them like that. Instead you use a Form object that take the object as a constructor argument and validates it's properties and provides validation errors.

form = CommentForm(request.POST)

if form.is_valid():
new_comment = form.save()
...
else:
...

<http://www.djangoproject.com/documentation/forms/>

Don't get stuck in the "one OO method to rule them all" mindset. The rings just weren't made that way. There's lots of right ways to do OO, figure out what works for you.

@Brian

I agree with Brian that putting security at the controller level presents an issue with remove access through something like Ajax or Flex. Though personally I think trying to do the same authentication model through AOP with a proxy for both is a big mistake too.

For instance twitter uses http authentication for web services, and totally ignores session management in the classical sense. So wrapping up the service layer in the same security model would have been a huge mistake. And also not scale nearly as well.

Google and all the other big services do the same thing now. They use standard login for http, and API keys for remote web service access.

Not every application sharing the same services necessarily uses the same security model either. Not even every context requires the same security. Sometimes we want to require permission X in context B, but permission Y in context A.

Sometimes we also want to totally side step the security model for some kind of inner service system or automation model. AOP and Proxies kind of solve this at a very rudimentary level with not a lot of control or context.

I think using an explicit filter approach works best because it stops you from ever having implicit security checks that your code isn't aware of so you don't get unexpected security exceptions.

The security is VERY explicit in your controller so you MUST handle it explicitly. If you forget, it's plainly visible because the check just ain't there.

I do this with named tiered permissions based on Permission objects that are mapped to them. I use URI notation for permission mapping names.

<cfif permissionService.isGrantedFor("blog.admin/post/delete")>
....
<cfelse>
...
</cfif>

We can do a lot of this in a request Filter, but a lot of it might also be very context sensitive. Like calling some kind of very specific method method. So it ends up in the controller and web services. Usually with different permission names...

isGrantedFor("blog.webservice/post/delete")

Maybe this permission requires an API key while the blog.admin one requires session based authentication.

Anyway, that's another way to do it. Best way is to try and learn and start simple to scale up. :)