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

1

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

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

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

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

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

public class ProjectController
{
    private ArrayList<Project> projects;

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

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

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

  • 2
    Объекты хранятся в модели, это и есть часть M MVC . Не обязательно сохранять данные, например, вы можете хранить их в куче, но затем они теряются после завершения работы вашего приложения.
Теги:
model-view-controller
grasp

4 ответа

2
Лучший ответ

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

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

Поделиться
  • 0
    Поэтому я должен создать отдельный класс с такими методами, как getAllProjects , getAllTasks , ... И этот класс затем возвращает желаемый список?
  • 0
    @Michiel - Да. Ваш контроллер не должен беспокоиться ни о чем, связанном с моделью (данными). Модель должна быть черным ящиком с контроллером. Так что вы можете легко изменить модель, не влияя на контроллер / представление. Создайте класс модели и вызовите его методы для получения данных.
Показать ещё 1 комментарий
2

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

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

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

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

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

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

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

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

Поделиться
  • 0
    Вы создаете класс php ? - Почему? .. Модельный класс может сделать это правильно?
  • 0
    @TheLostMind Это не неправильно, ИМХО. Я часто избегаю использовать класс модели для извлечения данных. Характеристики вашего источника данных могут измениться, не влияя на модель, или у вас могут быть разные источники для одного и того же типа данных.
Показать ещё 2 комментария
1

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

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

Поделиться
0

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

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

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

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

Поделиться

Ещё вопросы

Сообщество Overcoder
Наверх
Меню