Я пытаюсь смоделировать ситуацию, используя Java / Kotlin (на самом деле любой язык ООП). Я должен сделать приложение для управления задачами.
Требования
- Должен быть класс
Task и класс Tag
- A
Task может иметь несколько Tag s, а Tag может иметь несколько Task s, связанных с ним
- Каждый
Task может иметь несколько подзадач. Каждая подзадача сама по себе является Task
Я использую реляционную базу данных со следующими 4 таблицами:
- Задачи
- Метки
- TasksAndTags (относится к задачам и тегам)
- TasksAndSubTasks (связывает Задачи с Задачами для представления подзадач)
Схема базы данных довольно проста, но у меня возникают проблемы с выбором лучшего варианта в коде моего приложения.
У меня есть 3 варианта. Если вы предпочитаете GitHub, см. эту ссылку. Он выделил код.
Вариант-1
data class Tag (val id: Long, val name: String, val icon: Int)
data class Task(val id: Long, val name: String, val tags: List<Tag>, val subTasks: List<Task>)
Плюсы
- Дизайн более «объектно-ориентированный» и интуитивно понятный
Против * * тысяча пятьдесят-одна
Это действительно сложно использовать с реляционными БД. Циклы усложняют это еще больше
Я вынужден загружать все подзадачи каждый раз, когда загружаю задачу, даже если у меня вообще нет доступа к полю подзадач
Вышеприведенная проблема усугубляется тем, что каждая из этих подзадач может иметь свои собственные подзадачи
Вариант-2
data class Tag (val id: Long, val name: String, val icon: Int)
data class Task(val id: Long, val name: String, val tags: List<Tag>, val subTasks: List<Long>)
За
- Поскольку мы храним только идентификаторы, нам нужно загружать меньше данных
- Нет проблем из-за циклов
Против
- Использование идентификаторов похоже на реляционную модель, а не на объектно-ориентированную модель
* * Опция тысяча семьдесят-девять-3
data class Tag (val id: Long, val name: String, val icon: Int)
data class Task(val id: Long, val name: String, val tags: List<Tag>)
Плюсы
- Структура соответствует структуре сущностей / таблиц в нашей базе данных (минимизированный код отображения)
- Каждый отдельный объект маленький
Против
- Мы должны использовать другие методы доступа к подзадачам. Например, с помощью методов вида
getSubTasksForTask(task)
- Сам класс
Task ничего не говорит нам о существовании концепции подзадач
Вопрос1 : Эта проблема возникает из-за отношений между объектами. Я считаю, что эта ситуация действительно распространена, и должен быть хороший способ справиться с ней. Пожалуйста, дайте мне знать, какой вариант предпочтительнее и как минимизировать его минусы.
Question2 : Во всех вариантах я заставил Task удерживать их теги, но не Tag s удерживать их Task s. Хотя для меня это может быть интуитивно (не обязательно правильно), как лучше всего справляться с такими отношениями?
РЕДАКТИРОВАТЬ: я на Android. Так что ленивая загрузка для меня за пределами: (