1

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.

Stanko
  • 4,275
  • 3
  • 23
  • 51
  • 2
    Objects are stored in the model, that's what the `M` part of `MVC` is all about. One does not necessarily have to persist data, e.g. you can hold it on the Heap, but then it is lost after a shutdown of your application. – Smutje Mar 26 '15 at 10:18

4 Answers4

3

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

Unex
  • 1,747
  • 13
  • 17
  • *You create a php class*? - Why?.. The model class can do that right?. – TheLostMind Mar 26 '15 at 10:30
  • @TheLostMind It's not wrong IMHO. I often avoid using the model class for data retrieval. Characteristics of your data source could change without affecting the model, or you could have different sources for the same type of data. – Giuseppe Mar 26 '15 at 10:40
  • It depends, you can do both. Some people prefer to split the model into two class to have on one side the persistence and on the other side the fetch of the data. I only suggested that because since it's a school project, i assumed the purpose was to understand the way MVC works. I though it would be more instructive this way. – Unex Mar 26 '15 at 10:43
  • @Giuseppe - ya, the interface should remain constant. The source of data should be loosely coupled with the model. I was merely curious about the usage of php class. :) – TheLostMind Mar 26 '15 at 10:43
2

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.

TheLostMind
  • 35,966
  • 12
  • 68
  • 104
  • So I should create a seperate class with methods like `getAllProjects`, `getAllTasks`,... And that class then returns the desired list? – Stanko Mar 26 '15 at 10:25
  • @Michiel - Yes. Your controller should not be concerned about anything related to the model(data). The model should be a *blackbox* to the controller. So that you can easily change the model without affecting the controller / view. Create model class and call its methods to get data. – TheLostMind Mar 26 '15 at 10:28
  • What would be a suitable name for such a class? – Stanko Mar 26 '15 at 16:20
1

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.

Héctor
  • 24,444
  • 35
  • 132
  • 243
0

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.

coderz
  • 4,847
  • 11
  • 47
  • 70