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

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

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

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

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

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

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

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

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

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

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

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

• Запираемый
• Пригодный для публикации
• Помечаемый
• Приемлемый уровень
• Комментируемый

И т.д.

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

Все, что фактически не имеет никакого отношения к CakePHP, попадает туда.

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

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