платформы php - создают Ваше собственное по сравнению с предварительно сделанным
Я создаю приложение в настоящее время в PHP, и я пытаюсь выбрать, использовать ли существующую ранее платформу как codeigniter или создать мою собственную платформу. Приложение должно быть действительно масштабируемым, и я хочу полностью проконтролировать его, который заставляет меня думать, что я должен создать свое собственное, но в то же время я не хочу изобретать велосипед, если я не имею к.
Любой совет значительно ценится.
Спасибо
8 ответов
Используйте существующую структуру.
Прежде всего, создание фреймворка с нуля требует огромных затрат времени и усилий. Этот процесс включает в себя множество проб и ошибок, потому что вы разрабатываете что-то, что должно быть одновременно простым и мощным. При принятии каждого дизайнерского решения вы должны спросить себя, как оно повлияет на каждый будущий проект, который будет построен на вашем фреймворке.
Вы могли бы подумать, что можете принять каждое проектное решение и сопоставить его с требованиями, как если бы вы поступили с любым другим программным проектом, но дело в том, что вы не знаете своих требований. Вы не можете их знать, потому что фреймворк должен уметь делать почти все (или иметь возможность расширяться, чтобы делать почти все) в пределах своей области. Будущий проект должен уметь делать x. Может ли ваша структура позволить это, не превращая ее в спагетти-код? А что, если проекту b нужно выполнить y? Что, если проекту c нужно выполнить z?
Вы все спрогнозировали?
Теперь нормальная реакция на это: если что-то не сработает, вы просто измените это в будущем. В конце концов, это программное обеспечение. Однако фреймворк не похож на простое приложение. У него должен быть интерфейс, и как только вы предоставите его программному обеспечению, которое будет его использовать, вы не сможете его изменить. Вы можете продлить его, но не можете его изменить. Итак, теперь вам нужно подумать об устаревших методах, версиях API и совместимости версий. Это совершенно новый набор проблем, с которыми нужно иметь дело, наряду с обычным обслуживанием фреймворка и написанием новых приложений.
Тогда есть документация. Вам нужен API, руководства, пример кода.После того, как вы создадите свой собственный фреймворк, вам также придется иметь дело с этим. Вы можете проигнорировать это, но я уверяю вас, что в конечном итоге вам самому нужно будет выяснить, что делает этот метод, который вы написали 6 месяцев назад. Что это возвращает? Что, если случится особый случай x? Вы все это записали или вам нужно снова пройти через код? И я даже не буду упоминать, насколько легко новому члену команды будет начать работу над настраиваемым фреймворком, документация которого полностью или, по крайней мере, большей частью находится в вашей голове.
Вы также должны признать, что, если вы не работаете с самыми лучшими и умными (и не имеете соответствующего бюджета), у вас никогда не будет обширного набора библиотек, которым могут похвастаться существующие фреймворки. Можете ли вы анализировать, проектировать, кодировать, тестировать и отлаживать быстрее, чем сообщество разработчиков ПО с открытым исходным кодом?
Наконец, вы должны спросить себя, достаточно ли вы опытны, чтобы писать фреймворк. Вы углубились в код современного OO-фреймворка PHP5, чтобы узнать, что его делает? И самое главное, знаете ли вы , почему он работает именно так? Имейте в виду, что любая ошибка, которую вы допустили в своем дизайне, может взорваться вам через несколько месяцев, и вы можете в конечном итоге платить за нее снова и снова.
Подводя итог, я бы посоветовал вам использовать существующий фреймворк; однако это не означает, что вы должны выбрать один и он понравится. Выделите время, которое в противном случае вы бы посвятили разработке нового фреймворка, и посвятите его изучению существующего. Затем вы можете расширить его в соответствии со своими потребностями. Также помните, что могут быть вещи, которые вы не сможете сделать.Но я уверяю вас, что есть вещи, которые вы также не сможете сделать с помощью своего собственного фреймворка, так что это не имеет большого значения. Фреймворк накладывает несколько ограничений. Это цена, которую вы платите за возможность более быстрой разработки приложений.
Краткий ответ: symfony2 IHMO.
Причины:
- не изобретайте колесо
- хорошее колесо лучше вашего (другие - профессиональные производители колес, так как много времени)
- структура OSS может быть расширенным или модифицированным, даже только осмотренным
- сначала или позже у вас не будет времени поддерживать свое собственное колесо
- несколько глаз и рук делают это лучше, чем 2!
Конечно, предыдущие пункты действительны для очень небольшого набора профессионально сделанных фреймворков! Мне больше всего нравится symfony2, но есть несколько хороших альтернатив.
Я создаю свой собственный, и я очень рад, что сделал это с точки зрения обучения, что важно для меня. Также мне нравится полностью контролировать свой код. Однако у него много минусов, самый большой из которых - я единственный, кто знает, как его использовать. Кроме того, много времени на разработку уходит на улучшение моего фреймворка, а не на доставку продуктов моим клиентам. Но я не могу не подчеркнуть, что мне действительно очень нравится его создавать и использовать.
Если вы хотите научиться (МНОГО), создайте свой собственный. Если вы просто хотите поработать, используйте уже существующий. (Перед тем как начать свой собственный, я почти использовал CodeIgniter)
Хотя в прошлом я создал свой собственный CMS фреймворк и использовал пользовательские (собственные) общие php фреймворки, я бы нашел активный фреймворк, который подходит вашему стилю разработки, и использовал его.
Если только ваш основной продукт/приложение не является фреймворком. Но, похоже, это не так.
Ваши опасения по поводу контроля и масштабируемости должны быть применены к множеству существующих фреймворков - это даст вам короткий список вариантов, соответствующих вашим требованиям.
Конечно, это не вопрос "собственный" или "публичный", и после того, как вы сделали этот выбор, просто выберите любой старый фреймворк.
Чтобы ответить на вопрос, стоящий за вопросом, для фреймворка, который дает вам полный контроль и должен быть в состоянии масштабироваться разумно хорошо (я не уверен, как вам нужно, чтобы фреймворк масштабировался), я бы предложил Zend Framework. Вы можете использовать отдельные его части, переписывать то, что вам нужно, и это гораздо больше, чем просто реализация MVC.
Update: Быстрый пример кастомизации с помощью Zend. Если вы не хотите использовать их стек MVC, но вам нужно что-то для маршрутизации запросов, вы можете просто использовать библиотеку маршрутизаторов Zend. Если вам нравится стек MVC, но не нравится, как работает маршрутизатор, вы можете просто реализовать интерфейс и написать свой собственный маршрутизатор.
Это применимо и за пределами стека MVC. Zend имеет тонну библиотек для почты, rss-лент, кэширования, auth, db и т.д. Используйте то, что вам нужно, а остальное игнорируйте. Расширяйте то, что хотите, большая часть фреймворка состоит из интерфейсов/абстрактных/обобщенных классов, на которые вы можете опираться, если стандартная функциональность не удовлетворяет вашим потребностям.
Решение очень простое и простое.
Если вы хотите учиться и иметь полный контроль - выбирайте сами
Если хотите просто чтобы быстро зарабатывать деньги - переходите к готовому.
Я работаю в компании, которая изначально написала собственный фреймворк, созданный парнем, который здесь работал. Он использовался только в одном проекте. Причина в том, что вскоре мы поняли, что, хотя это было умно и очень хорошо, для него не было документации. Так что, если мы наймем другого разработчика или внештатного сотрудника, им придется этому научиться.
Некоторое время мы работаем с CakePHP, который пользуется популярностью, но кажется, что это беспорядок. В конце концов мы остановились на KohanaPHP. Легко расширить, хорошая документация (вероятно, не там, где есть другие), красиво отформатированный код (то есть, если вы не можете найти документацию, вы можете быстро понять, что происходит). То, как написан фреймворк, позволяет разработчику легко понять и следить за тем, что происходит. В то время как у нас всегда были проблемы с CakePHP.
Я думаю, что единственный аргумент в пользу развертывания собственного фреймворка - это то, что вам могут понадобиться какие-то сильно настраиваемые вещи. Но Kohana настолько легко расширяется, что вы можете просто добавить его туда. Вам не обязательно использовать их упакованные библиотеки, если вы действительно этого не хотите.
Тем не менее, в каком-то проекте я вообще не беспокоюсь о фреймворке, просто какое-то решение для маршрутизации, например GluePHP. Поскольку было бы излишним использовать фреймворк с полным стеком.
Если бы вы просто пытались попрактиковаться, я бы посоветовал написать свой собственный. В противном случае, тем не менее, определенно используйте существующий. Symfony ftw.
Составьте список требований для вашего фреймворка (ORM, PHP 5.3, PDO и т. Д.). Затем переберите существующие фреймворки и сузьте их, чтобы найти те, которые соответствуют вашим требованиям. Затем посмотрите на кодовую базу, документацию, сообщество, деятельность по проекту - чувствуете ли вы что-то, с чем вы хотели бы работать? Также реалистично оценивайте время, необходимое для самостоятельной реализации всех ваших требований - вы хотите сосредоточиться на создании приложения или фреймворка?