Аргументы за неиспользование фреймворка

Question

Некоторое время назад я прочитал отличную статью, в которой описан ряд причин, по которым нельзя использовать какие-либо платформы RAD, доступные для PHP.По сути, он утверждал, что хорошая основа должна быстро оторвать вас от земли, а затем уйти с вашего пути.Но ни одна из фреймворков PHP не сделала этого.Это указывало на то, что Django был хорош в этом (но это, очевидно, не PHP-фреймворк).

По жизни я не могу найти статью сейчас.

Так что ямне любопытноУ кого-нибудь есть веские аргументы относительно того, почему приложения не должны быть построены поверх платформы RAD?И я не обязательно говорю об универсальных приложениях (фреймворки по определению пытаются решить общую проблему. Вопрос в том, хорошо ли это переводит к конкретным проблемам).

И когда я говорю, что построен поверх, я имею в видус нуля на основе структуры.Я не имею в виду ссылаться на фреймворк как на ряд библиотек.Я имею в виду основывать всю архитектуру приложения вне фреймворка (который затем связывает вас с фреймворком).

Я также не говорю о быстром прототипировании, когда код в любом случае, вероятно, будет переписан.Я больше смотрю на долгосрочные приложения, которые имеют конкретные бизнес-требования и должны поддерживаться и поддерживаться (и модифицироваться) в течение относительно длительного периода времени.

Мы всегда слышим о том, почему мы должныиспользовать рамки.Есть множество причин:

• Не изобретать велосипед (хотя я ненавижу эту причину)
• Более быстрое время разработки (поскольку архитектура пропущена)
• Проще принести новоеРазработчики в
• Общие проблемы уже решены
• и т. д. *

Но я ищу антитезу ...

Любоймысли?

Answer 1

Подразумевается, что фреймворки пишутся некоторыми неизвестными героями, которые умнее вас по умолчанию.
Но на самом деле это часто не так.
В нем есть ошибки, он может быть грязным и излишним усложненным,Таким образом, иметь свою собственную вспомогательную библиотеку часто удобнее, чем использовать такого монстра, зная примерно 10% его возможностей.

Answer 2

Несколько идей:

1. Типовое приложение, которое вы создаете, не имеет коммерческой или бесплатной платформы (на ум приходят специализированные аппаратные приложения) (это очевидный ответ)
2. Система предъявляет требования к расширяемости, которые усложняются при использовании инфраструктуры RAD (т. Е. Соглашение о значениях инфраструктуры по сравнению с конфигурацией, где вам действительно нужна конфигурация)
3. Масштаб проекта достаточно мал, чтобы он неНе имеет смысла вкладывать кривую обучения в использование инфраструктуры RAD (если вы уже прошли кривую обучения, это может или не может применяться)
4. Требования к инструментам / подходу / бэкэнду / платформе, предоставляемыеФреймворк создаст ненужную сложность (YAGNI, использование фреймворка без потребности бизнеса в его функциях может увеличить затраты на поддержку, так как вам придется поддерживать все это, включая неиспользуемые функции)

Answer 3

Я всегда боялся, что произойдет, когда фреймворк перестанет поддерживаться / обновляться (по какой-либо причине)? Ваш проект заблокирован в любых версиях PHP / MySQL, поддерживаемых фреймворком.

Answer 4

В последнее время я провожу небольшое исследование фреймворка.
http://matrix.include -once.org / framework /

И в какой-то степени я должен согласиться.Большинство фреймворков не значительно упрощают разработку.В частности, фреймворки "MVC" - это больше абстракция, чем полезность.Однако всегда есть функции, которые помогают в повседневных задачах.ActiveRecord / ORM приходит на ум как сокращение утомительной ручной работы.Помощники форм могли бы это сделать, но я еще не видел серьезного помощника.

В общем, я считаю, что чем более функциональный библиотечный код обеспечивает инфраструктура, тем выше производительность.Но в случае с Zend Framework он случайным образом затмевается сложностью.Однако, проверьте некоторые из меньших структур.Избегайте чрезмерно абстрактного.Ищите инструменты для строительных лесов, а не библиотеки.

Answer 5

• Для развертывания некоторых сред требуется доступ к оболочке.
• Масштабируемость, я читал, что шардинг - это проблема
• Если производительность является приоритетом, фреймворки, как правило, замедляют скорость выполнения
• Не все разработчики знакомы с шаблоном MVC, поэтому удобство сопровождения может быть проблемой, если разработчики развернуты в / из проекта.

Answer 6

Одним из основных преимуществ отказа от использования фреймворка является то, что у вас больше гибкости в том, что вы можете кодировать. Для проектов с меньшим масштабом часто бывает лучше иметь такую ​​гибкость.