MVC pattern, нет базы данных, где хранить объекты?

Question

Я работаю над школьным проектом, и задача - разработать инструмент управления проектами. Нам разрешено использовать любой шаблон дизайна, если мы сможем объяснить, насколько это хорошо в соответствии с принципами GRASP.

Я дам краткий обзор инструмента проекта:

• CRUD-функциональность для проектов
• CRUD-функциональность для задач (проект имеет задачи)
• CRUD-функциональность для пользователей (а пользователю присваивается задачам)
• простой GUI

мы решили пойти с MVC-шаблон, и мы не разрешается использовать базы данных. Мой вопрос: Где я должен хранить объекты?

Должен ли я делать это в контроллере? В настоящее время мы делаем это так:

public class ProjectController 
{ 
    private ArrayList<Project> projects; 

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

У меня есть чувство, что что-то не так с сохранением объектов в контроллере, но я не могу объяснить, почему. Кто-нибудь, кто может объяснить, что является лучшей практикой в ​​соответствии с принципами GRASP?

EDIT: Спасибо, узнал от каждого, но может выбрать только один ответ.

Answer 1

Увеличение абстракции .. Создайте модельный ряд. Создайте свой arraylist (объекты модели). Контроллер должен по-прежнему обращаться к методам модели вызовов.

Завтра вы можете захотеть сбросить эти данные в файл или в БД, у вас будет одна адская поездка с этим проектом. Поэтому отделите свой модель от вашего контроллера и сохраните дизайн в чистоте.

Answer 2

№ Если вы храните данные в контроллере, вы не используете MVC. Вы должны сделать это в Модели. Вы можете хранить в памяти или файлах, но всегда хранить данные, бросая модель. Например, вы можете реализовать шаблон DAO для управления данными.

Возможно, не сейчас, но тогда вам понадобится база данных. С шаблоном DAO нетрудно будет адаптировать ваш текущий вид сохранения к базе данных.

Answer 3

Для очень короткого ответа: НЕТ, не помещайте свой магазин в контроллер. Это плохая идея, и это противоречит принципу MVC.

Обычно модель является единственным местом, ответственным за свои данные, но это часто, что M часть разделяется на:

• Извлечение данных.
• Хранение данных в приложении.

Интересная часть в этом заключается в том, что никто не заботится о том, откуда берутся ваши данные. База данных, файл, интерфейс API. независимо от того, это не имеет значения.

Я не говорю, что у меня есть лучшее решение для вас, но вот как вы могли бы сделать это на примере.

• Сохранение пользовательских данных в файл.
• Вы создаете класс php UserDataRepository, который извлекает файлы данных пользователя и устанавливает данные в ваш класс UserModel.
• С контролера вы вызываете свой UserDataReposiroty и возвращаете свой UserModel.

Таким образом, ваш контроллер не имеет представления о том, как вы извлекаете данные. Он просто запрашивает репозиторий для их получения, и он возвращает UserModel, который управляет контроллером.

Я надеюсь, что это поможет вам

Answer 4

В MVC шаблоне, M означает модель, V означает вид, C означает контроллер. Общий ход выполнения MVC заключается в том, что после поступления запроса контроллер получает его и выполняет необходимую обработку, извлекает данные результатов, а затем передает данные результатов для просмотра для рендеринга. После визуализации уровня отображения он отображается пользователям через графический интерфейс.

Таким образом, контроллер можно рассматривать как командующий, он контролирует процесс, но нехорошо обрабатывать извлечение данных в контроллере. Модель должна отвечать за получение и организацию данных. Это означает, что объекты данных должны храниться в модели вместо контроллера, контроллера вызывает Модели для извлечения объектов данных. Возьмите Java применения в качестве примера, как правило, необходимы эти части:

1. ProjectController, он вызывает ProjectService.getAllProjects() метод для получения результата. После получения, просмотр слоя использует результат для визуализации GUI для отображения. Я предлагаю, чтобы слой контроллера был тонким.
2. ProjectService, он имеет метод getAllProjects(), этот метод вызывает метод ProjectDAO.getAllProjects() для извлечения данных о проектах и, возможно, другой обработки. Здесь идет логика бизнеса.
3. ProjectDAO, он имеет несколько методов, которые имеют дело с объектами Project, обрабатывают данные в этом слое! Но эти методы должны быть независимыми с бизнес-логикой (поскольку бизнес-логика должна заключаться в ProjectService).
4. Project объект.

Надеюсь, что это поможет.