Where to put a certain kind of functions in MVC structure

Question

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.

Answer 1

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.

Answer 2

Model View Controler is really only about grouping together 3 seperate concerns, that is, responsibilities. It's an old design pattern created before we knew how to have objects interact.

View - Logic for displaying things to the user.

Correct. Remember there may be more than one of these.

Model - Database models.

Yes, well any model really. This is your programs state. Where you remember things you are, heh, modeling. Could just be some value objects like strings, ints and whatnot.

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

No.

That's only true of certain implementations of MVC. That means you look like this:

Which you can do. But you can also do:

Here the controller doesn't even know the view exists. "What knows about what?" is the best architectural question I know.

There are many other forms of MVC. If studying it leaves you feeling like a lot of things aren't nailed down then you've been paying attention.

What this means is deciding to use MVC doesn't mean that much. You still have to decide what knows about what and how to talk to it.

When I'm in the model I expect everything to be the basic way you create state. I don't want to deal with logic that makes decisions.

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.

Your model should have a basic API that allows it to be changed. If this is that, then this is the model. If not. If this is some fancy layer on top of the basic model API, then it's not really the model.

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

Well yes. MVC is the primordial goo of both architecture and design patterns. It's a good place to start but a poor place to live.

First of all study up on the observer pattern. It will teach you what events really are and explains why some of the arrows in these diagrams aren't the same.

Learn what the dependency inversion principle is. It helps make the lines you draw around your responsibilities meaningful.

When you're ready for architecture read up on hexagonal architecture. It's a different way to look at layered architectures. A nice variant of the hexagonal architecture is the clean architecture.

There is much more I could get into but that should give you enough to chew on for a while.

Answer 3

You need to establish relationships with your models. Relationships can be 1:1, 1:Many , Many:1 , Many:Many.

Taking your Example into consideration:-

1 User can make Multiple Posts

1 Post can have Multiple Comments.

So basically when you code your Model Classes it would be something like this:-

 /*
   Disclaimer: This is just an illustration. The actual code may differ depending on the technologies or frameworks that you use. 
 */

 class User {
    private String name;
    private String createddatetime;
    ....
    ....
    @OneToMany
    private Collection<Post> posts = new ArrayList<Post>();
 }

 class Post {
   ...
   ...
   @OneToMany
   private Collection<Comments> comments = new ArrayList<Comments>();
 }
 class Comments {
    private String freeText;
 }

With that being said, let's come to your Queries:-

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?

That is the Controller responsibility.

A controller can send commands to the model to update the model's state (e.g. editing a document). It can also send commands to its associated view to change the view's presentation of the model (e.g. by scrolling through a document).

The Controller's can either invoke Service methods which inturn invoke Dao methods which instantiate Models