Сумин Алексей бардекс

Публикации 8

Коментари 123

Отметки 9

Каква рамка ще използвате за писане на PHP приложения през 2016 г.?

Използване на прокси шаблона за организиране на кеширане в PHP

Изявление на проблема.Има работещ PHP проект с отстраняване на грешки, съдържащ дузина модела, всеки от които има 5 метода за вземане на проби от данни. Проектът се разраства, всичко е наред, но в един момент, под тежестта на товара, става необходимо по някакъв начин да се добави кеширане на моделни повиквания.

Първият начин "на челото":във всеки метод на модела добавяме кеширане според стандартната схема: проверяваме кеша, ако има действителни данни, връщаме ги, ако не, изпълняваме метода, както беше преди, и накрая също записваме в кеша данните, получени от базата данни. Да кажа, че това е ужасен начин, означава да не кажа нищо, така че просто ще кажа защо е лош:

  1. Нарушен е един от принципите на SOLID, "кодът трябва да бъде отворен за разширение, но затворен за промени", т.е. ние вземаме и прекъсваме вече дебъгвания код, пуснат в производство, за да добавим нова функционалност, и това винаги причинява вълна от грешки и, като резултат, недоволство на потребителите и клиента.
  2. Същият код смесва логиката за извличане на данни и кеширането, което води до раздути класове и безмилостно повторение на кода.
  3. Правейки това, ние губим способността да получаваме данни на живо, заобикаляйки кеша (следващата стъпка е да добавим флага $nocache).
  4. Много висока трудоемкост на кеширането по този начин и още по-голяма трудоемкост на изрязването му по-късно.
Вторият начин, „разширете класовете на модела“:добавете дублирани методи към модели, които обгръщат извиквания към съществуващи методи в кеширане, напримерfindById_Cached(). Изглежда, че е по-добре, ние не докосваме съществуващите методи, вместо това добавяме нови. Но останалите минуси са на място:
  1. Логика на смесване.
  2. Размерът на класовете нараства дори повече, отколкото в предишния метод.
  3. Много висока интензивност на труда (добавете 50 нови метода, в нашия пример) + заменете извикванията на стари методи навсякъде в приложението с нови и ако в бъдеще трябва да изрежете кеширането, повторете всички стъпки назад.

Третият начин е "caching proxy", много просто и бързо решение, което впечатлява със своята елегантност и скорост на изпълнение. Как да го направите - вижте кода.

Използване на делегиране с наследяване за организиране на контролери за действие

Добър ден колеги, днес ще разкажа история за моя опит в организирането на контролери в проект на ZF 1 (исторически се случи). Добрите книги за ООП често казват, че наследяването не трябва да се отнема, делегирането трябва да се предпочита или да се направи така, че да работят заедно. За съжаление, не винаги е възможно бързо да познаете как да приложите суха теория на практика (и когато най-накрая се стигне до нея, се чудите „какво е толкова трудно тук?“), така че се надявам моят опит да бъде полезен за някого.

И така, първо за проблемната област: 31 Controller Action, повечето от тях имат методи indexAction(), addAction(), editAction(), searchAction(). Проблем №1: Повечето, но не всички. В останалата част присъствието на тези методи варира, проблем #2: методите editAction() и addAction() са масивни сами по себе си иalmostса еднакви за всички контролери, инициализирането на формуляр и запазването на модела са различни.

Как го реших, ще ви покажа веднага в кода.

ORM в PHP да бъде или да не бъде?

Изследване. Как се разгръщате къмпроизводствен сървър(и)?