У вас класс зависит от контейнера. А то, что есть в контейнере или нет, он не знает, пока не спросит.
О том, есть 'nailer' или нет вы узнаете только во время выполнения специфической задачи. Самое простое - у вас может быть 10 методов, и вам придется их всех проверить, иначе во время жизни проекта может случится баг.
web-quest3: на чистом пхп я бы не советовал, особенно если будет такой человек, как заказчик. Хотя если это будет стоить для него две копейки, и он будет осведомлен, тогда можно.
Григорий Васильков: проблема в том, что вы все воспринимаете с точки зрения конкретной реализации, в то время ,как фреймворки предоставляют абстракции для работы. Окружение - это, грубо говоря, определенные условия выполнения кода. Т.е. вы можете реализовать, например, разные точки входа, в зависимости от каждой точки, ваш проект будет подгружать разные конфигурации и компоненты, однако , все это в рамках одного проекта(набора файлов).
Конфигурация - это тоже пользовательсские данные, которые тоже нужно валидировать, соответственно, если вы делаете фреймворк, то, возможно, захотите нормализовать работу с конфигурацией в подключаемых пользовательских модулях (бандлах, на примере symfony) . Вам может понадобиться не только работать с есть\нет поле и заполнить его, а проверить тип, несколько типов, классы по алиасу, роуты (возможно вам нужно передавать роут в параметре), в общем, создание отдельного конфигуратора расширит ваши возможности, вместо написания бесконечных костылей и полотен из if...else... .
Middleware - ищите по "Middleware php".
Model - это не про базу данных, это все привыкли для простоты понимания, что Model - это БД. Model - это комплексный слой, который включает и работу с хранилищами в рамках бизнес логики. И я вам написал свое предположение, почему во фреймворках так много файлов по сравнению с вашей реализацией, а не старался как-то разобрать ваш случай.
View - опять же, писал про фреймворк. Немного не понял вашего комментария.
Григорий Васильков: ну смотрите. У вас есть "главный файл", но по сути он у вас предоставляет один тип рабочей среды, окружения. Например в symfony, zendframework вы можете определять различные типы окружения под различные нужды с разными подключаемыми модулями. И оно, в принципе, интуитивно понятно.
Конфиги компнентов - вы сделали через массив ключ-значение, а могли бы сделать компонент конфигуратора, для которого можно было бы задавать схему конфигурации для каждого компонента, чтобы на этапе валидации конфига вам выскакивали ошибки о неверном типе ключа конфига, или отсутствии ключа, задвалось бы дефолтное значение и т.д.
Роутер - можно сделать просто парсинг, а можно сделать генерацию урла по роуту и параметрам, расширить валидацию с поддержкой header, можно сделать работу с middleware и и т.д.
DB - тут вообще куча вариантов реализации, UnitOfWork, QueryBuilder, Mappers и IdentityMap добавят не один файл в проект.
Identity ваш - тут вы смешиваете реализацию и абстракцию со службами (регистрация). В крупных фреймворках обычно идет поддержка различных типов авторизации - сессии, Http-based, token, JWT например. Плюс все это абстрагировано для подключения свои типов авторизации и ее обработки.
View - тут и шаблонизаторы и работа с параметрами, и работа с вложенностями (дочерняя вью и родительская), файлов тоже будет хватать.
Ну модели - это уже ваша бизнес логика, к фреймворкам не имеет отношения.
Максим Федоров: а что вы хотите вынести из архитектуры ? Это все абстракции, если вы используете ООП, то и Фаулер и Зандстра будут вам хорощим пособием в вашем вопросе, остальное покроет только личный, практический опыт. А вы, видимо, уже ищите конкретных решений.
Мне нужно вывести количество устройств которые были выключены за день в течении недели
Нифига не понял. Выключены количество раз, за день, выключены в течении целого дня за неделю, или выключены по количеству времени равное дню, за неделю ?
Евгений: вы задали конкретный вопрос, я ответил. WebDev вам предложил вариант отключения проверки наличия схемы. Вариантов море, от указания текстом на форме, до модифицированного input и сообщения с ошибкой валидации.
Т.е. если у вас, например ControllerManufacturer1 и у него свой конструктор, свои доп. методы, то можете его создавать через свой же метод createFromController(IController controller (который пришел из базы))
А когда вы принимаете данные, то можете просто вызывать этот класс, но вам, возможно (не знаю способности ОРМ в с#) создавать из него стандартный IController , чтобы поместить в базу.
Но для такого финта ушами, нужен хендлер\менеджер\etc. который будет это все дело разруливать. Т.е. внутри него вы должны будете зарегистрировать типы контроллеров. Т.е. когда из базу получаете контроллер, далее у вас есть список Manufacture\Type\Че-то там любой ключ => ClassName (класс конкретного контроллера), при получении вызываете у него метод createFromController и получаете конкретный экземпляр с методами и т.д.