LINUX.ORG.RU

[php] Как избавиться от «быдлокода»?

 


0

1

Здравствуйте.

Есть проблема: почти все сайты, что попадают ко мне на «допиливание» представляют из себя адскую смесь из php и html: в одном месте и оформление, и содержание, и логика, и даже пользовательские формы.

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

Собственно, вопрос: есть ли какое-нибудь учебное пособие (или статья) по переводу такого вида сайтов в нормальный вид, пригодный для дальнейшей поддержки?

★★★★★

> представляют из себя адскую смесь из php и html: в одном месте и оформление, и содержание, и логика, и даже пользовательские формы.

С PHP такое будет всегда и везде, вероятно, вы мечтаете про настоящее MVC

Alve ★★★★★
()
Ответ на: комментарий от Alve

>С PHP такое будет всегда и везде

Как будто шаблонизация — это что-то плохое.

настоящее MVC

Обоснованность применения MVC в деле сайтостроительства вызывает серьезные сомнения.

anonymous
()

Итак, мнения разделились. Пока больше всех голосов (и аргументов) в пользу Yii...

Igron ★★★★★
() автор топика
Ответ на: комментарий от anonymous

>Не панацея же.

Очень даже панацея. Через нормальный ORM и штатное его использование, не представляю, как инъекцию можно протащить.

Ты же сам прекрасно понимаешь, какой объем садового инвентаря идет в этой искаропке.

Если ты про объём кода — то не знаю, не знаю… Я всю свою «искаробки» даже на мелкие сайты—«визитные карточки» ставлю, даже когда они без БД, с диска данные из plain-text тянут :)

KRoN73 ★★★★★
()
Ответ на: комментарий от anonymous

>Обоснованность применения MVC в деле сайтостроительства вызывает серьезные сомнения.

Серьёзные сомнения вызывает программист, выражающий сомнение в применении MVC в деле сайтостроительства :)

KRoN73 ★★★★★
()
Ответ на: комментарий от Alve

>С PHP такое будет всегда и везде

Не нужно свои личные половые трудности проецировать на весь остальном мир :)

KRoN73 ★★★★★
()
Ответ на: комментарий от anonymous

И вместе с ним юзать TinyMVC. Они идеально сочетаются. Вдогонку – они от одного разраба.

Hertz ★★★★★
()
Ответ на: комментарий от Igron

Таких много. Есть профессиональные соцсети, есть непубличные проекты. Мы делали две социалки, у которых посещаемость сейчас > 100000 хостов в сутки. Проекты не публичные, ссылок не будет, все равно в открытой части там только форма для ввода логина и пароля :)

Дейтинги опять-же.. Тоже большую посещаемость имеют

ЗЫ Делали на Yii

boombick ★★★★★
()
Ответ на: комментарий от KRoN73

>как инъекцию можно протащить

Это все только ради непротаскивания инъекций? Но это же единственный не способ.

Если ты про объём кода

Я про всё. Например, меня смущает идея в качестве универсального решения каждому полю вебформы сопоставлять поле в таблице БД. И дело тут совсем не в оверхеде.

Я всю свою «искаробки»

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

anonymous
()
Ответ на: комментарий от anonymous

>Это все только ради непротаскивания инъекций?

Не только. Это просто контекст подветки.

Например, меня смущает идея в качестве универсального решения каждому полю вебформы сопоставлять поле в таблице БД

Обычно каждому полю БД соответствует свойство объекта. А уж как оно в форме будет — это вопрос совсем отдельный.

KRoN73 ★★★★★
()
Ответ на: комментарий от KRoN73

>Серьёзные сомнения вызывает программист, выражающий сомнение в применении MVC в деле сайтостроительства :)

Я не претендую :)

Технически, сайт можно рассматривать как клиент-серверное приложение, для которых MVC и было придумано. Значит, эта модель (черт, тавтология, тут две разные модели) применима при создании сайтов.

Но, проблема в том, что важные задачи, специфичные для создания и поддержки сайтов, MVC описывает либо никак, либо посредством былинных костылей, либо на слишком низком уровне («раскрутка», да).

С другой стороны, существуют не-MVC проекты сопоставимые с MVC или превосходящие их по показателю удельной трудоемкости создания и поддержки. (А зачем еще применять инструмент, как не для снижения затрат?)

anonymous
()
Ответ на: комментарий от anonymous

>Но, проблема в том, что важные задачи, специфичные для создания и поддержки сайтов, MVC описывает либо никак, либо посредством былинных костылей

Ткни пальцем в примеры. Интересно, что я упускаю :)

KRoN73 ★★★★★
()
Ответ на: комментарий от KRoN73

>Не только.

Именно. И если ОРМ делает пусть не всё, что она может, и даже не половину, но просто какой-то заметный объем работы, то просто применяем её и всё.

Обычно каждому полю БД соответствует

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

С другой стороны, ОРМ — костыль именно над рсубд, с nosql все сильно упрощается.

anonymous
()
Ответ на: комментарий от KRoN73

>Ткни пальцем в примеры

Раскрутка же, говорил. Ладно, назовем задачу «поисковая оптимизация контента». Разложишь её на M, V и C? «Контент» - а это термин предметной области - он, вообще, куда, в M, V или C? MVC вообще хоть как-то это описывает, или каждый вынужден изголяться в меру собственных представлений о модели?

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

anonymous
()
Ответ на: комментарий от anonymous

>С другой стороны, ОРМ — костыль именно над рсубд, с nosql все сильно упрощается.

1. Ты путаешь NoSQL и документо-ориентированные NoSQL :) Скажем, для хранения в тех же key-value всё равно нужна ORM.

2. ORM — это просто универсальный драйвер. С NoSQL я тоже работаю единым интерфейсом. Так что, в общем случае, у любого объекта теоретически можно в любой момент заменить бэкенд, не затрагивая систему в целом.

KRoN73 ★★★★★
()
Ответ на: комментарий от anonymous

>Ладно, назовем задачу «поисковая оптимизация контента». Разложишь её на M, V и C?

Видимо, я не понимаю, в чём суть этой задачи. Расшифруй.

«Контент» - а это термин предметной области - он, вообще, куда, в M, V или C?

Контент — продукт взаимодействия модели (исходные данные), представления (шаблон) и контроллера (которые обеспечивает связывание и выдачу).

KRoN73 ★★★★★
()
Ответ на: комментарий от xpahos

те дали проект - сказали запили фишку/напишы функционал, проэкт на пэхапе, ты будешь переписывать его с нуля на Ruby/Python?

umren ★★★★★
()
Ответ на: комментарий от Igron

Для верности повторюсь еще раз.

1) Те проекты которые вам дают на поддержание - весь быдлокод который там уже есть вы не перепишите, если работает - то не трогайте, если считаете геморройным заморачиваться с этим - задирайте ценник, рубите бабло :)

ПХП вцелом язык бабла, а не его любителей, все его люто ненавидят и пишут на нем, мечтая тайком перейти на «илитный» язык, но его распространенность в вебе просто феноменальна, поэтому возлюби врага своего.

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

umren ★★★★★
()
Ответ на: комментарий от umren

те дали проект - сказали запили фишку/напишы функционал, проэкт на пэхапе, ты будешь переписывать его с нуля на Ruby/Python?

Нет, зачем мне что-то переписывать? Пусть сами мучаются с допиливанием.

xpahos ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.