Преимущества создания пользовательского фреймворка MVC

Question

Было бы совершенно бессмысленно создавать собственную платформу php mvc для небольшого цифрового агентства?

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

Я бы подумал, что такая работа совершенно бессмысленна и действительно является пустой тратой времени и денег. Конечно, было бы более разумно выбрать фреймворк, который максимально соответствует вашим потребностям, а затем настроить / расширить его. На таких платформах, как Zend, код, безусловно, будет гораздо лучше / проверен, чем тот, который 1-2 программисты могли бы создать за несколько месяцев.

Это просто не имеет смысла для меня - кто-нибудь может преследовать меня иначе?

Answer 1

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

Поскольку они обеспокоены раздутой платформой, я предлагаю вместо этого исследовать использование облегченной среды PHP, такой как CodeIgniter и Kohana .

Answer 2

Использование вашей собственной инфраструктуры имеет одно большое преимущество перед другими решениями. Это означает, что у вас есть всего, я имею в виду ВСЕГО! контролировать это. Независимо от того, что происходит с другими платформами, потому что однажды у вас есть программное обеспечение с открытым исходным кодом, а в другой день оно может быть отменено или остановлено. И ваша структура все еще будет развиваться. Даже если это означает, что вам нужно будет постоянно добавлять некоторые функции, со временем это окупится. Кроме того, PHP как одна огромная структура в конце концов, и он развивается. Написание вашей собственной инфраструктуры позволит вам быть в курсе этой технологии :) Конечно, хорошо бы придерживаться других платформ или CMS, потому что, возможно, ваши клиенты захотят их использовать, и вы также можете учиться у них и перенести некоторые решения в Ваше программное обеспечение: D

Answer 3

Я вижу это бессмысленно.Но это проклятие PHP-программистов, которые склонны изобретать колесо снова и снова.Я знаю о чем говорю.Я тоже попробовал.

Лучший подход, кажется, состоит в том, чтобы изучить фреймворк, и если он вам не подходит, попросите друзей, которые знают другие фреймворки, узнать, как решается конкретная проблема в других фреймворках, и если нетони кажутся хорошими, тогда МОЖЕТ пришло время начать работу над новой структурой.

Точка с большим количеством неиспользованного кода не полностью действительна.Zend содержит классы, которые могут быть удалены, насколько я знаю.

EDIT: Производительность PHP может быть улучшена, например, с помощью eAccelerator .Я нахожу это проще, чем создавать совершенно новые рамки.

Answer 4

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

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

Answer 5

MVC FW составляет менее 5% от средней базы кода проекта, поэтому я настоятельно рекомендую создавать MVC для каждого проекта и адаптировать его к спецификациям проекта.Если у кого-то есть достаточно знаний о шаблоне MVC и некоторый опыт использования и построения сред MVC, его можно создать за несколько дней.

Общие аргументы - это скорость и производительность, задаваемые пользовательским FW.

Answer 6

Это зависит от того, какие проекты они делают, и каковы их потребности. Никогда не забывайте, что в программном обеспечении «лучшее» всегда зависит от того, что вы делаете. Не существует «единого золотого решения» для всего. Это включает в себя mvcs.

Существуют различные причины для кодирования вашего собственного MVC:

• Вы можете адаптировать его к вашим конкретным потребностям
• Вы можете держать это закрытым исходным кодом, уменьшая подверженность, повышая безопасность из-за неясности
• Вы можете продолжить его разработку, а затем выпустить его миру, когда он станет зрелым и выполнит основную задачу - так или иначе появилось много современных mvcs.
• Вы можете продолжить его разработку, оставить его закрытым исходным кодом и создать на нем массивные службы и приложения SaaS, на которые вы сохраните полные права. Может быть сделано и с лицензией apache.
• Вы можете выполнить цель, которая не выполняется ни одним другим mvc. Несмотря на то, что у каждого mvc есть свои фанатики, которые считают, что у них есть единственное решение, у каждого mvc есть свои недостатки. И верить в то, что «все, что можно сделать, было сделано», потому что есть 15-20 мвс, так же глупо, как сказать «все, что можно обнаружить, было обнаружено». И там были люди, говорящие последнее в начале 20-го века.

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

Не говоря уже о том, что их могут просто оставить. Может случиться с самым большим. Codeigniter был в моде. Что случилось ? Эллис сваливает это в основном. Развитие замедлилось. Вероятно, скоро полностью остановится. Быть открытым исходным кодом также не гарантирует проект - было много проектов с открытым исходным кодом, которые пошли подобным образом.

Что будет с людьми, которые закодировали основные приложения с помощью Codeigniter? Собираются ли они взять на себя безопасность установок Codeigniter, которые они имеют сами? Таким образом, де-факто стать хранителями своего собственного MVC? Или они собираются нанимать сторонних участников, чтобы поддержать их?

Не хорошие будущие инвестиции.

Я предпочитаю кодировать мой собственный mvc, в основном, чтобы иметь mvc, который соответствует моему стилю кодирования. Мои критерии для mvc:

• Быстрое развитие
• Быстрая модификация
• Низкие эксплуатационные расходы
• Скорость
• Безопасность
• Чрезвычайная простота
• Надежность в отношении будущего развития

Раньше я кодировал для себя основной MVC. и я до сих пор успешно запускаю его на одном из моих хобби-сайтов, который обрабатывает ~ 600 000-1 200 000 уникальных посетителей в месяц. В данный момент на сайте может присутствовать более 250 посетителей (Google Analytics - не включает никаких ботов), перебивая страницу за страницей. И это даже не мигает. Мне это нравится. Несмотря на то, что у него есть различные недостатки, которые мне не нравятся, он работает потрясающе.

В текущем mvc я делаю, я использую уроки, которые я извлек из предыдущего, поскольку они применимы к моим конкретным целям.

Не говоря уже о том, что это отличный способ оттачивать и развивать новые навыки.

Но одна вещь обязательна: планируйте это очень хорошо, и продолжайте строить на этом, изменяя и улучшая это.

Answer 7

Это пустая трата времени.Если они не создают сайт с трафиком Facebook, то хиты производительности, которые они получат, используя что-то вроде Yii, по сравнению с их собственным, должны иметь очень небольшое значение

Answer 8

Для любых рамок

Плюсы

• получите именно ту функциональность, которую хотите
• контроль над мелкими деталями, важными для вашего проекта
• знакомство с кодом

Против

• все, что ломается, ты должен исправить сам
• не учитесь на ошибках прошлого
• не получит столько замечаний из-за меньшей аудитории

Лично я рекомендую изучить существующие фреймворки, прежде чем даже подумать о написании собственных. Просто помните, что это нормально, если вы не понимаете всего этого за один день!

Answer 9

Это не обязательно пустая трата времени, но я согласен с вами, я тоже попробовал. Я использую Zend, Code Igniter и Fuel в зависимости от того, над каким проектом я работаю.

Следствием, которое я имел при создании моей собственной структуры, является крайний срок. Если вы работаете над проектом с очень жесткими сроками, то создание собственной платформы было бы плохой идеей.