MVC, куда идут занятия?

Question

Мое понимание MVC таково (если оно ужасно неправильно, я новичок в этом деле)

1. Модели - это вещи, которые взаимодействуют с базой данных
2. Представления - дизайн / макет страницы
3. Контроллеры - это то, с чего все начинается, и, по сути, логика страницы

Я использую CodeIgniter , но я бы рискнул предположить, что это не ограничивается этим или, возможно, даже просто PHP-фреймворками.

Где я могу разместить глобальные классы?

У меня может быть модель для Продуктов, и затем я запускаю запрос, который собирает 20 продуктов из базы данных. Я сейчас делаю 20 моделей или у меня должен быть отдельный класс для него, если последний, куда я помещаю этот класс (другие контроллеры должны будут использовать его тоже)

Answer 1

Модель - это неправильное слово, которое следует использовать при обсуждении того, что делать с продуктами: каждый продукт - это объект значения (VO) (или объект передачи данных / DTO, все, что у вас лучше умещается) Обычно объекты-значения имеют те же поля, что и таблица. В вашем случае ProductVO должны иметь поля, которые находятся в таблице Products.

Модель представляет собой объект доступа к данным (DAO) , который имеет такие методы, как

findByPk --> returns a single value object
findAll --> returns a collection of value objects (0-n)
etc.

В вашем случае у вас будет ProductDAO, который имеет что-то вроде вышеописанных методов. Этот ProductDAO затем вернет ProductVO и их коллекции.

Объекты доступа к данным также могут возвращать Business Objects (BO) , которые могут содержать несколько VO и дополнительные методы, специфичные для конкретного бизнес-случая.

Приложение: В вашем контроллере вы вызываете ProductDAO, чтобы найти нужные вам продукты. Возвращенные ProductVO затем передаются в представление (как атрибуты запроса в Java). Затем представление перебирает / отображает данные из productVO's.

Answer 2

Модель является частью вашего приложения, где происходит бизнес-логика. Модель представляет реальные жизненные отношения и зависимости между объектами, такие как: Сотрудник отчитывается перед Менеджером, Менеджер контролирует многих Сотрудников, Менеджер может назначить Задачу Сотруднику, Задача отправляет уведомление при просрочке. Модель CAN и чаще всего взаимодействует с базой данных, но это не является обязательным требованием.

Вид - это практически все, что может быть отображено или может помочь в отображении. Представление содержит шаблоны, объекты шаблонов, обрабатывает составление шаблонов и вложение, переносит заголовки и нижние колонтитулы и производит вывод в одном из хорошо известных форматов (X / HTML, но также XML, RSS / Atom, CSV).

Контроллер - это слой перевода, который переводит действия пользователя в операции модели. Другими словами, он сообщает модели, что делать, и возвращает ответ. Методы контроллера должны быть как можно меньше, и вся бизнес-обработка должна выполняться в модели, а логическая обработка представления должна выполняться в представлении.

Теперь вернемся к вашему вопросу. Это действительно зависит от того, нужен ли вам отдельный класс для каждого продукта. В большинстве случаев достаточно одного класса, и нужно создать 20 его экземпляров. Поскольку продукты представляют бизнес-логику, они должны принадлежать части модели вашего приложения.

Answer 3

@ Александр упоминает CakePHPs Поведения , Компоненты и Помощники . Они отлично подходят для абстрагирования от общей функциональности. Я считаю Поведение особенно полезным, поскольку, конечно, основная часть бизнес-логики передается в моделях. В настоящее время я работаю над проектом, в котором у нас есть такие поведения, как:

• Lockable
• 1012 * к опубликованию *
• Tagable
• соответственный
• Commentable

и т.д.

Для кода, который выходит за рамки даже инфраструктуры MVC, т.е. библиотек кода, которые вы используете для различных вещей, которые не привязаны к конкретной платформе, которую вы используете - в нашем случае, например, к классам кодирования видео и т. Д. CakePHP имеет поставщиков папка.

Все, что фактически не имеет ничего общего с CakePHP, идет туда.

Я подозреваю, что CodeIgniter не имеет такой гибкой структуры, он меньше и легче, чем CakePHP, но кратко рассмотрим руководство CakePHP , чтобы увидеть, как Поведение, Компоненты, Помощники и папка Vendors может быть полезным

Должно быть легко включить некоторые общие вспомогательные классы из ваших моделей, оставьте все в порядке и DRY

Answer 4

Самый простой способ:

1. Иметь класс модели для каждой таблицы базы данных. В этом случае это будет объект, в котором хранятся все данные о продукте.
2. Поместите эти классы в пакет / пространство имен, например, com.company.model (Java / C #)
3. Поместите классы DAO в пакет вроде com.company.model.dao
4. Ваше представление будет использовать данные из сеанса / запроса / контроллера. В этом случае у меня будет список .
5. О, вы используете PHP. Не знаю, как это меняет вещи, но я думаю, что у него есть структура коллекций, как и любой современный язык.

Answer 5

В CakePHP есть еще 3 "части":

1. Поведение
2. Компоненты
3. Помощники

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

(Компоненты помогают контроллеру совместно использовать логику, а помощники - аналогичным образом).