MVC pattern, no database, where to store objects?

Question

I'm working on a school project and or task is to design a project management tool. We are allowed to use any design pattern as long as we can explain how it's good according to the GRASP principles.

I'll give a synopsis of the project tool:

• CRUD-functionality for projects
• CRUD-functionality for tasks (a project has tasks)
• CRUD-functionality for users (a user is assigned to tasks)
• A simple GUI

We decided to go with the MVC-pattern and we are not allowed to use a database. My question is: Where should I store objects?

Should I do this in the controller? Currently we do it like this:

public class ProjectController
{
    private ArrayList<Project> projects;

    public ProjectController(TaskController taskController)
    {
        projects = new ArrayList<Project>();
    }
}

I have a feeling there is something wrong with keeping the objects in the controller but I can't explain why. Anyone that can explain what's the best practice according to the GRASP-principles?

EDIT: Thank you, learned from everyone something but can only pick one answer.

Answer 1

Increase abstraction.. Create a model class. Create your arraylist (model objects) there. Your controller should still access/call model methods.

Tomorrow, you might want to dump that data into a file or into a DB, you will have one hell of a ride doing that with the current design. So separate your model from your controller and keep the design clean.

Answer 2

In MVC pattern, M means models, V means view, C means controller. A common MVC application progress is that once a request is coming, controller get it and do necessary processing, retrieving results data, then pass the results data to view for rendering. After view layer is rendered, it displays to users via GUI.

So controller can be regarded as a commander, it controls process, but it is not good to handle data retrieving in controller. Model should be responsible for retrieving and organizing data. That means data objects should be stored in Model instead of Controller, Controller calls Model to retrieve data objects. Take Java application as example, usually these parts are needed:

1. ProjectController, it calls ProjectService.getAllProjects() method to retrieve result. Once retrieved, view layer use the result to render GUI for display. I suggest Controller layer should be thin.
2. ProjectService, it has method getAllProjects(), this method calls ProjectDAO.getAllProjects() method to retrieve projects data, and maybe other handling. Here business logic goes.
3. ProjectDAO, it has several methods which deal with Project objects, deal with data in this layer! But these methods should be independent with business logic(as business logic should be deal in ProjectService).
4. Project object.

Hope it helps.

Answer 3

No. If you store data in the controller then you are not using MVC. You have to do it in the Model. You can store in memory or files, but always store data throw the model. For example, you could implement DAO pattern to manipulate data.

Maybe, not now, but then you will need a database. With DAO pattern, it won't be difficult to adapt your current persistence kind to a database.

Answer 4

For a very short answer : NO, don't put your store in the controller. This is a bad idea and it goes against the MVC principle.

Usually, the model is the only place responsible for your data BUT it is frequent that the M part is split into :

• Fetching the data.
• Storing the data in the application.

The interesting part in this is that, no one cares where your data come from. A database, a file, an API rest. whatever, it doesn't matter.

I'm not saying i have the best solution for you but here is how you could do this with an example.

• You store your user data into a file.
• You create a php class UserDataRepository that fetches the user data files, and sets the data into your UserModel class.
• From the controller, you call your UserDataReposiroty and get back your UserModel.

This way your controller doesn't have any idea how you are fetching the data. He just asks a repository to fetch them and it returns the UserModel that the controller is allowed to manipulate.

I hope this will help you