Loading...

Във форума е въведено ограничение, което позволява на потребителите единствено да разглеждат публикуваните въпроси.

white.shark avatar white.shark 2 Точки

Добри практики в PHP

Здравейте,

от известно време гледам лекциите по PHP и се опитвам да решавам домашните. Имам един въпрос относно добрите практики при писане на код. По-конкретно искам да питам за писането на PHP в HTML. Например, ако имам някакви по-големи цикли или сложни логики които трябва да се изпълняват в HTML, кое би било по-добра практика? Да си ги "набутам" директно в HTML-ла и да стане грозно и по-трудно четимо или да си ги направя на функции и просто да ги викам там където трябва?

Благодаря

2
PHP Web Development Basics
brslv avatar brslv 69 Точки
Best Answer

За целите на нашия курс, дали пишеш директно в HTML-а или не, няма кой знае какво значение, тъй като работиш в един файл и нещата са ясни.

Когато обаче става въпрос за средно-големи и големи проекти, най-вероятно ще ти се наложи да използваш ООП. Причините са много, но фактът е, че няма уважаваща себе си фирма, която пише PHP директно в HTML-a  (валидно не само за PHP).  Добрата практика е PHP да се пише обектно, като логиката и презентационната част са изцяло разделени. Можеш да срещнеш тази концепция като MVC - Model, View, Controller. 

Когато пишеш PHP (и какъвто и да е друг език за уеб), винаги се стараеш да не мажеш. Една от причините, поради която много хора хейтят PHP е защото не са запознати с езика от версия 5.2-3 нагоре. Преди това можем да кажем, че наистина е било голяма мазня! 

Обаче.

PHP в момента разполага с приличен обектен модел, който позволява да се имплементират много от доказалите се в практиката шаблони за дизайн. И пак се връщам на MVC. Това си е архитектурен шаблон, който определя основните правила, по които ще постигнеш разделението на логическа и презентационна част, или казано по-грубо - php - html. 

Става въпрос за следното. 

В най-чистия случай, MVC дефинира мястото, където ще се случва бизнес логиката на приложението - модела. Там се прави връзка с бази данни, обработват се различни потоци от информация, вземат се съществени бизнес решения (логин, регистрации, извличане и въвеждане на информация в БД, валидации (задължително в модела)). 

След като тази информация се обработи, тя се подава в суров вид на презентационната част, която трябва да я визуализира на клиента. Според MVC, обаче, това предаване на информация трябва да премине през контролера. Контролера е този, който решава спрямо информацията, която е дошла при него от модела, към кое view да я подаде. Негова е задачата да я подаде и в добре структуриран формат. Най-често се използва масив от елементи.

View-то, това, за което питаш, трябва да получи информацията готова, структурирана и ясна. Пак казвам - най-често масив от някакви елементи. Във вюто няма проблем да пишеш много проста логика, но не и бизнес логика. View-то е най-глупавия елемент от MVC, ако мога така да се изразя - то не трябва да мисли, валидира, прави връзки с БД и т.н. То получава информация и я показва. Толкова.

Това е много, много, много грубо представяне на MVC, без детайли. Но важното в случая е да разбереш, че това, което пишем в СофтУни е един много остарял подход (смесване на HTML и PHP директно), който от PHP 4 нагоре никой средно-интелигентен дев не използва (btw, ако гледаш видеа в тубата, повечето пишат процедурно, директно в HTML, което не е най-готиното решение...). Към момента пишем така, за да свикнем със синтаксиса на езика, да схванем как той работи и който се ориентира бързо - да разбере, че процедурното PHP е лошо и така не се прави.

Когато минем през ООП, КПК и т.н. курсове, много от нещата ще станат ясни. Надявам се. Що се отнася до PHP, пак казвам, правилният начин за писане на съвременен PHP код е обектно, разделяйки максимално логиката от презентацията. И удебелявам - говоря за бизнес логика (БД, обработка на данни, валидации и т.н.). Основната цел е да успееш да събереш, обработиш и подготвиш информацията, която искаш да покажеш на потребителя и подавайки я във view-то просто да я обходиш с един прост цикъл там. Нищо повече.

Някъде тук бях попадал и на видео на Марио Пешев, който пишеше някакво приложение с MVC. Гледах 20-тина минути и горе-долу хубави неща видях. Намери го(в някой от предните курсове) и ще ти се изяснят много неща. 

Дано съм бил полезен. : )

4
30/04/2015 10:34:47
mgulubov avatar mgulubov 73 Точки

Ако циклите или логиките са ти прекалено големи/сложни и се изпълняват бавно, не мисля, че ще има значение дали ще са директно в html-a или ще са отделно. При такава ситуация, то по всяка вероятност, ти е грешна логиката, по кято си ги създал. Добре е, винаги да си държиш кода подреден, не само заради лесната четимост, а и заради възможноста да го модифицираш по-лесно при нужда. Разделяй и владей :D.

1
BoYaN avatar BoYaN 336 Точки

Здрасти,

тук са събрани правила и насоки за правилно писане и структуриране на PHP код, не е официлно, но примерно в PhpStorm има доста от тези неща вкарани в редактора им.

2
RoYaL avatar RoYaL Trainer 6849 Точки

TL;DR; няма добра причина, ако имаш сложни логики те да са при HTML-а. Само условни конструкции и цикли за рендиране на HTML са допустими в презентационната част.

4
Можем ли да използваме бисквитки?
Ние използваме бисквитки и подобни технологии, за да предоставим нашите услуги. Можете да се съгласите с всички или част от тях.
Назад
Функционални
Използваме бисквитки и подобни технологии, за да предоставим нашите услуги. Използваме „сесийни“ бисквитки, за да Ви идентифицираме временно. Те се пазят само по време на активната употреба на услугите ни. След излизане от приложението, затваряне на браузъра или мобилното устройство, данните се трият. Използваме бисквитки, за да предоставим опцията „Запомни Ме“, която Ви позволява да използвате нашите услуги без да предоставяте потребителско име и парола. Допълнително е възможно да използваме бисквитки за да съхраняваме различни малки настройки, като избор на езика, позиции на менюта и персонализирано съдържание. Използваме бисквитки и за измерване на маркетинговите ни усилия.
Рекламни
Използваме бисквитки, за да измерваме маркетинг ефективността ни, броене на посещения, както и за проследяването дали дадено електронно писмо е било отворено.