MVC Design – Where to Put Certain Functions

architectural-patternsdesign-patternsmvc

I'm just starting out using programming using the MVC design pattern, and I would like to know if I understood it correctly and where I should put certain things.

So I understood that I should put all my files in one out of three folders, (or just separate the code):

Model – Database models.

Controllers – logic that deals with moving the info stored in the models to the view and the other way around.

View – Logic for displaying things to the user.

So my question is if I have some functions that help me deal with models, but isn't a model itself, where should I put it?

For example, let's say I have the next models: User, Post, Comment.
And I created a function called "Add", and it receives the two arguments: "model name" and "properties" for that model, and the function uses the requested model and doest all the work needed to add it to the database.

And is there any good structural pattern you think I should get a look at?

EDIT: I saw that both answers I received are conflicting, so here I have a better example.

Let's say I have different types of "entries", they can be Articles, Blogs, a Video, etc…
I already have a model for each one of them with the right relations between them and their comments, and the other things.

All those entries, share a common "basic structure", and they can be dynamically created.

So I created a function to help me manage those entries, and it receives the name of the entry, and the properties to be saved to the database., then that function sends that data to the appropriate model.

Here is the pseudo code representing the function:

function add( modelName, properties ) {

    // Checking the inputs.

    // Checking if a model with that model name exists

    // Pass the properties to the right model

    // Try to save it to the database

    // Return errors/updates.
}

EDIT: I'm sorry I update with so many questions, it's just the best way I know for understanding stuff 🙂

So another question: Where is the right place for validating user input? should it go to the model?

And where do I check permissions of the user to access information?

If I understand correctly most of the logic goes into the Model?

And one last thing, I'm not familiar with most of the terminology of the MVC so please explain to me as simple as possible.

Best Answer

if I have some functions that help me deal with models, but isn't a model itself, where should I put it?

If these are helper classes for the Model, they should sit with the Model. Note also that the Model isn't just the database models, it's actually the domain model. Your business logic and business rules reside there, not just your business entities.

I created a function called "Add", and it receives the two arguments: "model name" and "properties" for that model, and the function uses the requested model and does all the work needed to add it to the database.

This sounds like your persistence layer. Persistence should be part of the Model, at least that's how I've used it and I think it should be, although there are lots of variations of MVC.

In deciding where some code, class, function, etc should live (M, V or C) it's a good idea to keep in mind the base reason MVC exists and that is to separate concerns. With a good MVC implementation it should be relatively easy to replace the C or the V with a different implementation. So when you do that, would you need to provide another implementation for "Add" or should that already be available within the M? (*)

(*) = Note that I'm not saying that your persistence should be tightly coupled with M - you should have a persistence layer that you can mock or replace if you need (for example, from a DB to using a web service) - I'm saying that it goes together with the M.

EDIT: to respond to the new questions you asked

Where is the right place for validating user input? should it go to the model?

Validation goes in both the Model and the Controller. But there are two kinds of validation.

User input is validated inside the controller. Did the user fill in all the mandatory fields? Did we receive all that's needed to make a call to the Model? This kind of stuff. The controller then massages the input into parameters for the Model. For example, you usually submit stuff as Strings but the model might expect an Integer. The controller adapts the input data and makes sure it's valid for a Model call.

Now the Model does it's own validation. Checking the received parameters and checking business rules. It doesn't care about the user input, it cares about the received parameters on the call. Like I mentioned above, the idea is to think about replacing the parts of MVC. If you replace the controller and the new implementation is buggy and does not do a proper job of sending the parameters to the model, should the model just trust them and not do anything to validate them? It should validate them.

And where do I check permissions of the user to access information?

In MVC this is placed most of the time inside the controller. That's because interactions of the user with the model pass through the controller, the controller is the entry point. Most people stop there. The model isn't called if the controller sees you do not have the right permissions. Again, if you replace the controller or add a new one, the new implementation needs to protect the model. If it's buggy or the developer forgets, you can end up making a call to the model event though you were not supposed to.

So security should be applied to both the controller and the model. The model checks that a business call is allowed while a controller checks that an entry point is allowed. For example you can access an URL just fine if you are logged in or not (controller allows it either way), but you can access some feature from that URL only if you are logged in (model does not allow anonymous roles).

Hope this is of help to you. As was mentioned in the answers, MVC comes in a lot of flavors and depending on the applications, needs, understanding of developers, access medium (web MVC vs desktop app MVC), etc, a certain behavior might be implemented in different ways.

Related Topic