[katello-devel] Apipie and validation.

[Dmitri Dolguikh]

On 03/12/12 09:36 AM, Lukas Zapletal wrote:
>> Step #1 - let's get rid of controller validations.
> Again, you can only do this for CRUD actions in the controllers. For all
> other methods we need validations. And we have those, not all our
> controllers are plain REST-driven. We do have procedure-like actions.
> Maybe more then we should have, but this is a fact.
>
> You say all the validations should be done in models, thus you
> essentially say let's put all our code logic there. Because it does not
> make sense to do validations in models while doing anything else (that
> also requires some level of validations) in controllers or a logic
> layer. A fact: you need to do validations also outside of models.

Domain logic belongs in the model layer. We can discuss how to better 
factor model layer code, but not where to put it.

-d

A lot of rationalizations to keep validations in apipie have been put 
forward, *all* of them attempting to deal with various smells, code or 
process ones. Let's fix the root issues.

Again, Let's get rid of validations in apipie. Refactor the controllers 
when needed. If apipie is not useful without those validations, let's 
suspend/stop use of it.

-d


>
> It is wrong to put all your code logic into models. And unfortunately we
> have most of it there. Rails follows MVC pattern and what we have is those
> messy Models-for-everything approach. If you mix this with our
> orchestration, it is deadly combination. Difficult testability, huge
> objects with no responsibility split, unable to mock things and so on.
> Code logic in models works well for small projects and it is de-facto
> standard in Rails world. People just blindly follow this wrong pattern.
>
> So I don't agree with this simplification you offer. We will likely
> start to refactor our orchestration creating new layer of code logic,
> which is the right approach to do things. And we should move complex
> methods like activation key subscription from models there. Then we will
> need validations on the controller side (or on the newly created logic
> layer or orchestration layer - depends on how are we gonna name it).
>
> So yes, it has something to do with REST. My counter proposal is:
>
> #2 Let's get rid of validations where they duplicate model validators,
> but let's keep them for (usually non-CRUD) methods which need then. We
> will likely be extending those soon.
>