Pull to refresh

Comments 34

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

P.S. ORM Doctrine2, реализующая в PHP паттерн Data Mapper, выпущена в 2010 году.
Раз уж Вы все знаете, может подскажете почему он так слабо применяется? Вещь реально, имхо, крутая. И почему он в Doctrine2 называется Repository?
Можете привести ссылки на статистические данные, демонстрирующие слабое применение Doctrine (учитывающие, что Doctrine используется далеко не только в Symfony)?

ORM, построенные на AR — это большая скорость разработки и меньшие требования к квалификации разработчиков. Для малых и (частично) средних проектов разработка на AR обходится дешевле, чем на DM.
Как Вам такая идея (давно ее лелею): автор статьи, является дискжокеем, вы открываете статью и у вас играет музыка: Lana Del Rey — Music To Watch Boys To

Ну согласитесь автор старался, статью написал, это же честно, что-бы у «зашедших» играла его музыка?
UFO just landed and posted this here
Вообще, Data Mapper плохо описан в Wiki, но по примерам я понял, что там делается наследие от некоторого базового класса, потом можно применять. В призрачных SQL — не нужно строить дополнительные классы. Просто пользоваться тремя вышеописанными методами, и итоге получить два функциональных аспекта. Во-первых, накапливать SQL update/replace/update, во-вторых, имеется возможность хранить много переменных в одной ячейке. Да и вообще, я указал вначале статьи, что похожие методики используются в ORM, но не нужно строить или пользоваться ORM чтобы иметь этот функционал под рукой
накапливать SQL update/replace/update</>
Это не data mapper это unit of work

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

Вот зачем!? Зачем я в ночь на праздник увидел этот код!? Бедные мои глаза!

С точки зрения администратора БД ORM — это 1с, производительность которого можно залить деньгами, но и то не всегда. Все же сильно правильнее, когда запросы к БД формализуемы, таблицы корректно индексированы, а кеш таки используется по назначению…
Потому поддерживаю про малые и иногда средние проекты.

По окончанию работы скрипта, вызывается callback функция для register_shutdown_function(), в котором собственно осуществляется (или нет) реальный SQL запрос в БД.

А если скрипт не оканчивает работу — как быть?
А если скрипт оканчивает работу, но shutdown-функция не выполняется?
1. Если скрипт не оканчивает работу, вызовите вручную когда надо SKY::here(), это же просто :). Если вы заметили, то в тексте написано «как правило»…
2. shutdown-функция всегда выполняется, иного не наблюдал ни разу в php начиная с 5.4.
Ошибок до регистрации callback хендлера быть не может (чтобы он не сработал), — не то место, чтобы там писать код приложения. Да… shutdown-функция может не выполниться, когда выполняется другая и в ней выполнили exit. — не нужно писать другие shutdown-функции, это тоже просто (это не прерогатива кода приложения). Никогда я не видел чтобы это была проблема.

Я так понимаю, ваш пост — попытка поймать меня на элементарном незнании PHP, но если вы хоть немного смотрели мою работу, то это глупо, иначе вы сами не знаете элементарный PHP
Я ни на чём вас не ловлю, просто задал вопросы. Вы почему-то упустили вариант, когда на сервере просто пропадёт питание — тогда shutdown-функция явно не будет выполнена. Соответственно весь код нужно писать с оглядкой на то, что shutdown-функция выполнена не будет, а если мы каждый раз обрабатываем эту ситуацию — тогда зачем вообще shutdown-функция?
Если пропадает питание, то никакой код не будет выполнен, который подразумевалось что должен. Любой критически важный код, например финансовые транзакции, нужно писать «с оглядкой». Если писать конфигурационный код, то часто «оглядка» не нужна, например у меня в системной конфигурации прописана размер авки 100х100 если я прописую 120х120 и в этот момент вырубили свет, то после того как включили, я просто проверил руками, успел ли прописать, если нет,- еще раз повторил. Так что оглядка должна быть всегда, но здесь вы упоминаете не по теме. Я описую идею, основные моменты. А вообще пользуйтесь ИБП :)
Вообще я подводил мысль к транзакциям и согласованности данных в разных компонентах системы, в частности к многофазных коммитам, но кажется вам это ни о чем не говорит.

Нужно рассматривать все возможные ситуации и обрабатывать их, иначе получится то, что называется «неопределённое поведение», которое может быть как безобидным, так и критичным, вне зависимости от того сохраняете вы «размер авки» или «финансовые транзакции».

Самое главное — вы забываете о переиспользовании кода. Сегодня вы сохраняете «размер авки», а завтра у вас юзеры платят за «размер авки» деньгами которые попадают в «финансовые транзакции». Ваш код могут использовать только юзеры с ИБП, по вашей логике.
Ваша коллаборация с Тарасом КТЛ взорвёт интернеты. Пожалуй, это единственный человек, который может воспринять ваш фреймворк всерьёз, свяжитесь с ним.
1. Не получается зарегистрироваться на сайте вашего фреймворка, чтобы принять участие в разработке, на почту приходит ссылка, но когда по ней перехожу выдает «попытка взлома заблокирована». Пробовал несколько раз.

2. Не нашёл списка контрибьюторов, сколько живых человек принимает участие в проекте?

3. Можете привести несколько сайтов реализованных на этом фреймворке?

4. Есть ли пример исходного кода небольшого типичного проекта реализованного на этом фреймворке? Чтобы можно было быстро оценить как выглядит практика его применения.
1. coresky код постоянно обновляется, к сожалению иногда происходят такие накладки. Попробуйте зарегистрироваться через OAuth2 вашего аккаунта Google, доселе OAuth2 регистрация была устойчива. Тесты тоже пока не написаны, чтобы быстро фиксить такие вещи, если бы было хотябы 5 человек у меня — было бы проще.
2. Я один и финансирования 0, поэтому хотелось бы найти серьезное финансирование желательно за бугром а не в совках и человек 5-6 хороших программистов, которые хотя бы изредка ранее повторяли мантру «что-то с PHP right way все-таки не так»
3,4. Cмотрите в разделе загрузок — MED.CRM.SKY. Там есть DEMO и стабильный код сайта без одного файла (локально развернуть рабочую копию не сможете). Это код не самый свежий (в нем нет SKY-GATE (небесных врат), о них можете прочесть статью), но все-же в нем используется одна из последних редакций coresky кода. В данный момент я работаю над SKY-GATE, работа не закончена.

ru.coresky.net/download
Поремонтировал регистрацию через email — должна работать, извините за неудобство.
Выслал вам недостающий файл на вашу почту яндекс, так что сможете развернуть локально MED.CRM.SKY.
Уважаемые читатели хабра, я пишу по-видимому свой последний пост на хабре! Это не значит что я сдался, я просто не буду больше писать на хабре и отвлекать ваше внимание. По итогу за эту мою статью проголосовало 12 в минус и 11 в плюс. Я обращаюсь к тем кто проголосовал в минус. Вот реально без стёба, очень прошу, кто-нибудь может написать, реально, что плохо? Без стёба, пожалуйста!
В коде для повторного использования, для организации «призрачных запросов» необходимо иметь три метода

Почему именно три? Что они должны делать?


, первый приведу полностью, так как он довольно прост:

Может он и прост, но настолько безобразно написан, что разбираться в нем нет никакого желания.


где скопом хранятся все переменные призрачных запросов $char.

Эм… Шта!?


И т.д. Какой-то бессвязный поток сознания.

Спасибо за честный ответ.
У меня когда-то в контактах был чел у него в статусе было написано: «Я и сам не понимаю своих идей», я сейчас понял для чего. Ну не умею, я делать красивую обертку. Честно говоря, я рассчитывал, что тот кому нужно, прочтет дополнительную одноименную статью на моем сайте, — там подробнее описано.
Но тем не менее, признаю, я плохо постарался. Обещаю по возможности исправить эту статью.
UFO just landed and posted this here
Позволю себе уточнить, что именно не так с кодом:
1. Для таких комментариев следует использовать phpdoc. И его же следует использовать для описания аргументов функции.
2. У функции слишком много аргументов. Названия аргументов не дают понять, за что именно эти аргументы отвечают.
3. Использование глобальных переменных, — это как минимум моветон. Не следует использовать global.
4. В современном PHP есть очень удобный тайпхинтинг, хорошо бы его здесь использовать.
Боюсь вас рассмешить, но по поводу глобалов читайте мою предыдущую статью. Я настаиваю на том, что PHP right way и большинство PSR — ошибочная рекомендация. Объекты $sky и $user (как минимум) нужно чтобы были пользовательскими (точнее фреймворка) суперглобалами, нет смысла инжектить их повсюду и использовать длинные имена. Тоже самое «phpdoc» хрень несусветная, сорри за французский.

PSR это клетка

Иногда нужно всё разрушить, спалить всё дотла, чтобы потом начать всё сначала.
— Клей (Ирвин Уэлш)
Эти слова красиво звучат в одной из песен группы Флёр
www.youtube.com/watch?v=rU6EXBkL2d0&list=RD4uQaxCS84Io&index=6
UFO just landed and posted this here
Реквестирую отдельную статью с обоснованием. Даёшь разрушительную критику PSR, но не голословную, а по конкретным пунктам с конкретными примерами.

Касаемо паттерна God Object, который у вас реализован как global $sky, — намного лаконичнее сделано например в Yii — статическая переменная класса.
Я не тот человек, который бы мог дать разрушительную критику, я не умею делать красивые обертки, да и тема такая — попробуй только сделать красивую обертку… сложно. может лет через 5-10 когда почва будет… Я уже и так много здесь, на хабре сказал.
Статическую переменную я делал вначале, это выглядит длинно, потом решил вернуть global $sky; А в идеале должно быть суперглобал например %sky, %user читайте предыдущую статью.
UFO just landed and posted this here
UFO just landed and posted this here
UFO just landed and posted this here
Вы написали свой код только по той причине, что весь остальной открытый код имеет фатальный недостаток (надеюсь всем знаком этот термин). Ваш реальный уровень знаний не соответствует тому уровню, на котором вы себя видите.
Пока же вы занимаетесь изобретением того, что уже есть. И это, на самом деле, — неплохой подход, — но это не то, что интересно.
Рискну сделать предположение, что вы довольно молоды и лет через 5-10 ваши статьи будут более благосклонно восприниматься сообществом.
Почитал статью и заминусил на всякий, чтобы этого больше никто не видел.
Sign up to leave a comment.

Articles