Как сформировать правильную структуру MVC фреймворка?
Вопрос по ООП (PHP) от начинающего.
Пишу свой MVC фреймворк. Основу написал: модели контроллеры вьюхи. Есть ядро фреймворка - где лежат файлы родителей модели, контроллера и вью, в них соответственно лежат общие для потомков методы и свойства.
В проекте который будет на этом фреймворке, кроме вывода некоторой информации, нужно будет работать с физическими устройствами, отправляя им пакеты с данными и получая ответ. Т.е. зашёл на главную страницу, получил некий текст и ответ (состояние) неких устройств. По логике вещей все методы для работы с устройствами необходимо собрать в одном классе контроллере и соответственном классе модели, обеспечивая связность кода.
Не могу понять, как тут поступить:
а). то ли размазать код для работы с устройствами по контроллерам и моделям, в зависимости от того на какую страницу человек попал, то и отработало?
б). то ли создать отдельный класс и отдельную модель, что мне нравится больше, но каким образом и в какой момент подключать этот класс, то ли как-то встроить его в дерево наследования, то ли положить его вообще отдельно и в какой-то момент создать объект?
Вопрос в том, где грамотно с точки зрения MVC и ООП в целом поместить такой код для работы с устройствами?
Видимо вы хотели написать: "Зачем тебе, дурья бошка, свой фреймворк писать, если уже готовых целый мешок - выбирай какой хочешь". Это потрясающе мудро, правда не является ответом на вопрос.
Я пишу свой фреймворк, чтобы понять вообще что это такое. Так как разбираться в уже готовых мне сложно.
Прекрасная логика! Чтобы стать пилотом - собрать свой самолёт, чтобы научиться играть в футбол - построить стадион, чтобы научиться играть в шахматы - вырезать фигурки из дерева, чтобы научиться плавать - построить бассейн. Спасибо что заходите что нибудь написать. А по существу - да, чтобы понять как создаются языки программирования будет уместным написать свой, пускай кривой и примитивный.
А вот в этом то вся и "МАГИЯ" профессионализма разработчиков фреймворков!
Ответ: б
Подключение класса - при первом востребовании объекта с проверкой на существование из любого места (через глобальный "сквозной" массив-реестр запрошенных классов и не только).
Для каждого устройства - свой отдельный класс.
Средний