Давайте посмотрим на мой файл docker-compose (django):
version: "3"
services:
education:
image: mysql/mysql-server:5.7
ports:
- 3308:3306
environment:
- MYSQL_USER=cuong
- MYSQL_PASSWORD=cuong
- MYSQL_DATABASE=education
volumes:
- .:/education/db
esmweb:
links:
- education
build:
context: .
dockerfile: Dockerfile
volumes:
- ./:/education/
image: django
stdin_open: true
tty: true
ports:
- 8080:8080
и посмотрите на тома. Это как кеш. когда ваш код изменится, он изменится напрямую. и когда вы хотите удалить данные контейнера, вы можете сделать: docker-compose down
Надеюсь, что это поможет вам. Вы можете прочитать документы, чтобы узнать «тома»: тома
У меня обычно есть один контроллер для каждой логической группы функций. Часто это будет соответствовать одному контроллеру на модель, иногда нет.
Предположите создание простого интернет-каталога, который отображает список категорий затем, когда пользователь выбирает категорию, отображает список продуктов от той категории, наряду с панелью администрации для CRUD
операции на категориях и продуктах. У меня было бы две модели (CategoryModel
и ProductModel
). У меня был бы контроллер, который генерировал списки категорий для фронтэнда и другой контроллер, который генерировал списки продуктов (например. CategoryController
и ProductController
). У меня затем был бы контроллер для категорий и продуктов на бэкэнде (AdminCategoryController
и AdminProductController
). Эти два внутренних контроллера обработали бы, перечисляют/добавляют/редактируют/удаляют/просматривают операции для их соответствующих моделей. Если Вы будете думать, хотя Ваша структура URL и поместила связанные функции на связанные URL, то Ваша структура контроллера будет часто соответствовать Вашей структуре URL. На самом деле некоторые платформы (например, CodeIgniter) запросы маршрута на основе названия контроллера как поведение по умолчанию.
Что касается того, что входит в контроллеры, я работаю в идее, что Модели для доступа к данным, и переносят и скрывают структуру базы данных. Логика те, которые "присваивают текущее время completion_date, когда состояние установлено 'завершиться'", является великим пригодные модели.
Представления содержат полноту Вашей презентации. Контроллеры/Модели не должны генерировать или обрабатывать HTML. Решения, такие как 2 столбца или 3 принадлежат представлений. Логика в представлениях должна быть ограничена тем, что требуется, чтобы генерировать видимый вывод. Если Вы желаете для запросов базы данных от представления, Вы, вероятно, помещаете слишком много логики в представление.
Контроллеры для того, что оставляют. Обычно это означает, проверяя вход, присваивая данные формы моделям, выбирая правильные представления и инстанцируя моделей, требуемых обрабатывать запрос.
По большей части я следую за шаблоном контроллера на модель. У меня есть несколько контроллеров, которые могут служить многоуровневым моделям (как Администраторский контроллер, который служит нескольким административным моделям), но общее правило является одним контроллером на бизнес-модель.