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