Комментарии 6
Вы описали проблему, с которой столкнулись при использовании CI. А какие преимущества он дал? Может быть его использование не оправдано и проще написать полностью «свой» код, и не тратить время на борьбу с ПО сторонних разработчиков?
Мне в CI нравится работа с БД и роутер и как по мне — для мелких проектов фреймворк вполне годный.
Для всяких крупных и нестандартных штук наверное всё таки лучше Symfony, но я к нему пока не привык.
А полностью писать свой код наверное всётаки не стоит :)
Разработчикам всегда приходится выходить за рамки существующих решений — это не значит что существующие решения не нужно использовать.
Мы же не будем конструировать новый велосипед если нам понадобится прикрутить к нему фонарик :)
Вопрос только в том, что бы правильно выбирать велосипед.
Для всяких крупных и нестандартных штук наверное всё таки лучше Symfony, но я к нему пока не привык.
А полностью писать свой код наверное всётаки не стоит :)
Разработчикам всегда приходится выходить за рамки существующих решений — это не значит что существующие решения не нужно использовать.
Мы же не будем конструировать новый велосипед если нам понадобится прикрутить к нему фонарик :)
Вопрос только в том, что бы правильно выбирать велосипед.
Мне в нём лёгкость, скорость и меньше количество писанины по сравнению с другими нравится. На выходе лаконичный и лёгкий для поддержки код из-за низкого порога вхождения.
А так-же безболезненная расширяемость — подключение любых сторонних библиотек, ORM, шаблонизаторов безболезненно проходит. В общем, конструктор «собери свой фрэймворк».
А так-же безболезненная расширяемость — подключение любых сторонних библиотек, ORM, шаблонизаторов безболезненно проходит. В общем, конструктор «собери свой фрэймворк».
«собери свой фрэймворк» читать как каждый раз собери новый велосипед, взяв старую любимую ржавую половинку рамы?
Низкий порог вхождения имеет смысл когда у вас куча быдлокодеров за еду (читай макдональдс)
Из-за низкого порога вхождения «лаконичный и лёгкий для поддержки код» может получится только на сайте из нескольких страничек — а так — чем дальше тем страшнее.
Логично что расширяемость там присутствует — автолоад как-бы в php есть.
По сути то там есть дохлая система работы с базой которая слав богу хоть худо-бедно плейсхолдеры поддерживает, да роутер по одному формату class/func/params. Ну еще пару мелочей в виде прибитых гвоздями хуков, да и либ/плагинов, даже без автолоада, а со своей кривой системой.
Низкий порог вхождения имеет смысл когда у вас куча быдлокодеров за еду (читай макдональдс)
Из-за низкого порога вхождения «лаконичный и лёгкий для поддержки код» может получится только на сайте из нескольких страничек — а так — чем дальше тем страшнее.
Логично что расширяемость там присутствует — автолоад как-бы в php есть.
По сути то там есть дохлая система работы с базой которая слав богу хоть худо-бедно плейсхолдеры поддерживает, да роутер по одному формату class/func/params. Ну еще пару мелочей в виде прибитых гвоздями хуков, да и либ/плагинов, даже без автолоада, а со своей кривой системой.
Стоит немного шагнуть в своём решении за рамки модели MVC, возникает проблема — как включить это решение в проект.
Нет, стоит просто отделять понятие «модели» в MVC от его реализации в конкретном приложении или фреймворке. Вообще говоря, слой доступа к данным (DAL) в БД, ФС или по каким-то ещё протоколам (http например) к модели не относится (если мы не пишем админку к БД, файловый менеджер или браузер). Но с легкой руки создателей паттерна ActiveRecord эти понятия для многих слились :(
Быть может стоило использовать в данном случае Driver Library вместо создания фабрики? Судя по документации это весьма подходящее и элегантное решение в данной ситуации. Я конечно могу ошибаться…
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Встраивание своей классовой структуры в проект на CodeIgniter