Преимущества создания пользовательского фреймворка MVC
Было бы совершенно бессмысленно создавать собственную платформу php mvc для небольшого цифрового агентства?
Недавно я слышал от друга, что его колледжи фактически проводят время для такого проекта в своем агентстве. Их аргумент против использования другого, такого как торт или зенд, заключается в том, что они имеют так много неиспользуемых функций и, следовательно, много ненужного кода.
Я бы подумал, что такое начинание совершенно бессмысленно и действительно трата времени и денег. Конечно, было бы более разумно выбрать фреймворк, который максимально соответствует вашим потребностям, а затем настроить / расширить его. На таких платформах, как Zend, код наверняка будет гораздо лучше / проверен на уровне, который 1 или 2 программисты могли бы создать за несколько месяцев.
Это просто не имеет смысла для меня - может ли кто-нибудь преследовать меня иначе?
6 ответов
Нет, я думаю, вы найдете здесь большинство, которые согласятся с вами - я определенно считаю, что это пустая трата времени. Особенно с учетом того, что это небольшое агентство, их ограниченные ресурсы можно было бы лучше потратить в другом месте.
Поскольку их беспокоит раздутый фреймворк, я предлагаю вместо этого изучить облегченный фреймворк PHP, такой как CodeIgniter и Kohana .
Я считаю это бессмысленным. Но это проклятие программистов PHP, которые склонны изобретать колесо снова и снова. Я знаю, о чем говорю. Я тоже пробовал.
Лучшим подходом кажется изучение фреймворка, и если он вам не подходит, попросите друзей, которые знают другие фреймворки, узнать, как конкретная проблема решена в других фреймворках, и если ни один из них не кажется подходящим, то МОЖЕТ БЫТЬ пора начать работу над новым фреймворком.
Пункт с большим количеством неиспользуемого кода не совсем верен. Zend содержит классы, которые, насколько мне известно, можно удалить.
РЕДАКТИРОВАТЬ: Производительность PHP можно повысить, например, с помощью eAccelerator . Мне это проще, чем создавать новый фреймворк.
MVC FW составляет менее 5% от средней кодовой базы проекта, поэтому я настоятельно рекомендую создавать MVC для каждого проекта и адаптировать его к спецификациям проекта. Если у кого-то достаточно знаний о шаблоне MVC и некоторый опыт в использовании и создании фреймворков MVC, он может быть построен за несколько дней.
Общие аргументы - это скорость и производительность, предоставляемые пользовательской прошивкой.
Для любого фреймворка
Плюсы
- получите именно ту функциональность, которая вам нужна
- контроль над мелкими деталями, важными для вашего проекта
- знакомство с кодом
Минусы
- все, что ломается, вы должны исправить сами
- не сможете учиться на ошибках прошлого
- не так много ошибок будет замечено из-за меньшей аудитории
Лично я рекомендую изучить существующие фреймворки, прежде чем рассматривать возможность написания собственного. Помните, что ничего страшного, если вы не поймете все за один день!
Это пустая трата времени. Если они не строят сайт с трафиком Facebook, то производительность, которую они получат, используя что-то вроде Yii по сравнению с их собственным, не должна иметь большого значения
.Иногда, когда люди боятся изменений и изучения нового, они придумывают всевозможные глупые причины, почему что-то плохо и не должно использоваться.
Однажды я работал в компании, которая была полна решимости написать собственный веб-фреймворк вместо использования Django. Один из разработчиков, который работал над «админской» частью фреймворка, сказал, что я хотел, чтобы он потерял работу, потому что в Django есть автоматически сгенерированный админ.
Если это не очень конкретная структура, и у вас есть очень веские причины и достаточно средств для проекта, никогда не стоит изобретать велосипед специально, если вы не можете сделать его такого же или лучшего качества, чем то, что уже существует.