Комментарии 71
Так как просто читать «о программировании» — это не то.
Надо ручками, ручками — кодить, думать, анализировать.
фреймворки — это не то на чем поднимается скил.
Приведу пример:
- ваш логгер — вы не рассмотрели случаи когда нужно делать блокировку на файл для предотвращения конкурентной записи
- вы используете статику и суперглобальные переменные по всюду в коде.
- нет тестов (то что есть — не то что нужно для "фреймворка")
- в целом вы "повторили" то что уже знали, я подозреваю что знаете вы Yii. Никаких новых скилов.
А вот если бы вместо этого вы бы просто на PHP написали логику какую сложную, поработали со структурами данных, написали бы e-commerce решение (только логика, ни баз данных ни прочего) с какими-нибудь сложными скидками и купонами, вот там есть где покачать скил. Особенно если при "качании скила" наложить кучу ограничений на свой код (аля никаких геттеров, ну или взять просто "объектную гимнастику"). Вот эти ограничения вас думать заставят. Ну или попробовали бы по TDD работать (phpspec желательно, ну или хотя бы phpunit, а не codeception который позволяет тестить любой код) отбросив все свои старые привычки. Это тоже будет "чем-то новым" для вас.
А так… просто еще один фреймворк который не должен увидеть продакшена.
Хочется интегрировать программную составляющую (что писать: структуры, сложная логика, объекты и т.п.) и общественно-полезную составляющую (для кого для чего писать, суть самой разработки, её полезность для людей).
и общественно-полезную составляющую
С этим сложно, это надо думать и смотреть чего не хватает комьюнити. Было бы круто иметь такой вот список "хотелок" с возможностью пообсуждать имплементацию.
Посмотрите чего не хватает инфраструктуре PHP. Я бы например предложил бы вам сделать солюшен вроде attache, и даже звездочку бы поставил.
Еще как вариант — leaderboard для PHP, потом возможность истории впилить.
Еще — можно попробовать попилить фичи для популярных библиотек/фреймворков.
По ходу эксплуатации различных современных фреймворков я понял, что недостаточно понимаю, как все устроено внутри, ..., я выбрал создание собственного проекта.Чукча не читатель, чукча писатель!
Презентацию очередного фреймворка лучше всего со сравнения с существующими. Так читатель может понять, на какую нишу этот фреймворк претендует. Для этого нужно хорошо разбираться в существующих решениях. Если же вы начали писать свой ради того, чтобы не изучать чужое, вас ждет сизифов путь.
Я пробовал отключать этот код — но тогда ничего не работает.
Добавлял такие конструкции:
"psr-4": {
"Frm\\": "/system/",
"App\\": "/application/"
}
Но не дошел до работающей конструкции.
:(
Добавлял такие конструкции
А после добавления файл автозагрузки пересобирали?
Мне кажется, что для текущей конструкции этот этап уже наступил — т.е. фукнциоанл перевалил за какую-то граничную точку, когда это уже не учебный проект, а нечто самостоятельное и жизнеспособное.
Если поэксплуатировать этот фреймворк на продакшне в течении 6-9 месяцев (с постоянной доработкой и сопровождением реального проекта) — то после этого срока можно будет сделать програмный редизайн и рефакторинг кода ядра и всего приложения в целом.
Может получиться следующий релиз, качественно отличающийся в лучшую сторону от предыдущего, с более богатым функционалом, протестированный и т.п.
Вот для этого и пишу о поиске реальных проектов.
Нет, не надо применять это "на реальных проектах", пожалуйста. Миру уже хватает проектов на no-name фреймворках которые нереально суппортить.
Суть использования "чужих решений" раскрывается в том, что если у решения есть комьюнити то стоимость поддержки этого решения распределяется по всему комьюнити. А когда это самое комьюнити состоит из одного человека — дешевле будет взять готовые компоненты и склепать свой клей вокруг.
Полагаю, что пространства имен с маленькой буквы навеяны Yii2. Не вижу ничего плохого в этом. Стандарт PSR-4 об этом умалчивает, поэтому это дело вкуса как их обзывать.
То что касается CoreException вовсе странная претензия. По вашему расширять класс исключений нужно только для того чтобы добавить новый функционал или переопределить конструктор?
в yii то понятно это так сложилось, это их стиль и всё такое, но все пакеты нынче используют UpperCamelCase. Так зачем следовать за таким редким стандартом. Да и смотрится потом при использовании сторонних пакетов это стремно.
Скажите это PSR
https://github.com/php-fig/log/blob/master/Psr/Log/InvalidArgumentException.php
Очень удобно ловить исключения, относящиеся к конкретному модулю/библиотеке/etc, а не все подряд
Этим вы подтвердили мои догадки о том, что понятия не имеете как работать с исключениями.
что за прикол с двумя конфигами которым нужно ещё и array_merge делать?
Это сделано для того, чтобы указывать уникальные настройки (например коннект к БД) только в одном месте, а потом — объединять настройки из разных файлов для запуска текущей конфигурации приложения.
Например: у нас есть фронтэнд, бекэнд и консоль. Коннект к БД хранится в одном файле.
В каждом приложении мы подключаем конфиг самого приложения и конфиг с настройками коннекта к БД.
Получается просто и универсально (ка на мой взгляд).
В общем конфиге коннекта к этой базе нет, конфиги разделены.
Есть очень много способов решить указанную задачу. Я привел лишь один из них.
Не хочется хейтить или негатив лить. Но простите, я не очень понимаю зачем вы это выложили. Нет оно конечно даже боли ваш код не вызвал. Для себя в академических целях, прекрасное занятие.
Дам пару советов что стоило бы поменять: про неймспейсы вам уже сказали, ту да же и автолоад.
Еще очень просится разделить код самого ядра с его тестами и непосредственно приложения на его основе. Вынесите его в отдельный пакет.
Управление ассетами в контролере и конфигах бекенда как то неуклюже, не их это дело.
Php как шаблонизатор если используете то имхо лучше использовать <?= ... ?> вместо <?php echo ...; ?> и для управляющих конструкций вариант синтаксиса с :. Т. е.
<?php foreach(): ?>
...
<?php endforeach ?>Шорт-теги (<?=) — зло, и использовать их нежелательно
Потому что потому?
так лучше ещё и нагородить свою функцию вместо echo
<?= escape($data) ?>
Не вариант?
Функцию экранирования это само собой. Т. е. в идеале нужен нормальный шаблонизатор. Но если мы используем просто php шаблон то делаем функцию
/**
* @param mixed $value
* @return string
*/
function e($value)
{
return htmlspecialchars((string) $value, ENT_QUOTES, 'UTF-8', false);
}и используем её: <?= e($some) ?>
Шорт-теги (<?=) — зло
У вас устаревшая информация. Во первых шорттеги считались злом потому что могут быть не включены. Но с PHP 5.4.0 именно <?= не считается шорттегом и директива конфигурации на него не влияет.
редакторы кода не находят такие логические блоки
Я не знаю чем вы пользуетесь. Мой шторм справляется. Но смысл что эти теги делают более читаемым код и без сворачивания
По поводу шорт-тегов — признаю, как-то пропустил этот момент когда они перестали быть злом
Мне кажется вы не до конца правильно понимаете ситуацию. Шорт-теги остались злом. Но конкретно тег
<?= к этому злу не имеет отношения, так как конфигурационная опция, связанная с шорт-тегами, на его работоспособность не влияет после версии 5.4.У вас "неправильный" шторм
Еще очень просится разделить код самого ядра с его тестами и непосредственно приложения на его основе. Вынесите его в отдельный пакет.
Ага, пришел так же к этому (вообще узнал о такой возможности недавно).
лучше использовать <?=… ?> вместо <?php echo ...; ?>
Да, буду переучиваться себя на такой стиль.
Одно время были споры по поводу коротких тегов.
Рад что сообщество вернулось к <?=… ?>
«Узких» мест много.
На своем опыте я понял, что чем больше пишешь — тем больше разрастается код, тем больше надо думать об архитектуре и общей схеме вызова компонентов.
Список «К исправлению» увеличивается и увеличивается, а для каждого исправления — надо много читать и думать об оптимальных решениях.
И тесты писать и прогонять их после каждого изменения в ядре.
Положительным моментом всей этой затеи является то, что квалификация и опыт программирования растет так же с исправлением каждой ошибки. Но цена этого опыта — перебор горы пустой породы в поисках того алмаза.
Хотя другого пути нет, никто за человека это не сделает, кроме него самого.
По коду. А что будет, если нам подсунули не инстанс контроллера?
if ($controller instanceof Controller) {
$controller->setApplication($this)->run();
}
Молча проглотим? Хотя если класс не существует, то кидаем исключение. Не аккуратненько…
Со «своей колокольни» не все видно (или видно недалеко), а так все накидали комментариев по чуть-чуть — понятно что с этим всем делать и что есть в сухом остатке на данный момент.
База данных: MySql >=5.4.*
Это что за зверь такой? После версии 5.1 сразу же идет 5.5
потому что это самый простой способ сделать взаимодействие с БД. Даже DAO сложнее потому что думать больше надо. А тут — есть табличка в базе и она 1:1 мэпится на объектик. Ну и еще — многие кроме AR ничего и не юзали.
Плюс у AR есть приличное кол-во недостатков, которые уже в моем случае превосходят его преимущества. Поэтому нужно как-то людей толкать в сторону сущностей, репозиториев и дата-маперов.
Т. е. вы "практически ничего не использовал кроме AR" и при этом уверены что где то там солнце ярче?
модель == один класс == active record (я тоже так думал еще 2 года назад).
На примере Eloquent ORM: так есть такие понятия как аксессоры, мутаторы, скопы и тп. Работая со всеми этими терминами в контексте одного класса «модель» становится не много неповоротливой. Дальше более продвинутые новички, которые почитали про «MVC», и узнали примерно такую цитату "… Контроллеры должны быть тонкими, а логика должна быть в модели...", придерживаясь вышеупомянутого сравнения начинают логику писать в моделях (а в 99% это 1 класс).
В результате появляется весьма не очень хорошая практика и очень много не очень хороший статей и видео по теме.
Что касается меня, я не использовал скажем доктрину вне учебных целей, поэтому не могу топнуть ногой и сказать, что я все попробовал на достаточно уровне. Однако сейчас я пишу модульную архитектуру где все-же есть AR, однако он фигурирует только в реализации репозиториев, при этом, что очень важно, из репозиториев возвращаются сущности.
А так все получилось, потому, что очень сложно объяснить новичку, который 10 лет пишет на AR, почему нужно создать еще 5 классов, а не один AR.
но он практически всегда приносит жесткий дискомфорт
Ну можете перейти на уровень выше — row data gateway. Это когда у вас над каждой "моделькой" или графом "моделек" представляющих именно модель данных, есть объекта модель которая представляет корень агрегата например.
Можно по разному готовить работу с базой данных. И вы редко ограничены каким-то одним подходом. Причем даже в одном проекте могут быть ситуации при которых надо комбинировать подходы.
Поэтому нужно как-то людей толкать в сторону сущностей, репозиториев и дата-маперов.
или DAO.
— сущность
— репозиторий
— для некоторых вещей View Model
А вот реализация уже использует AR. И то очень аккуратно, так как строить запросы в нем очень легко. А с помощью View Model иногда можно возвращать кастомные штуки, чтобы не плодить частичные объекты (http://docs.doctrine-project.org/projects/doctrine-orm/en/latest/reference/partial-objects.html).
В теории я тестировал, реализацию можно подменить без проблем, так как на выходе единый формат сущности или view model
Кто у вас отвечает за сохранение сущности (кто дергает save)? Как разруливаете связи? Что у вас является сущностью? Выделяете ли корень агрегата сущностей?
чтобы не плодить частичные объекты
partial objects из доктрины слегка бесполезная штука. Мне больше импонируют выборки с select new SomeDTO(u.id, u.name)...;
Тут проблема в другом. Вам действительно все это надо? Особенно например репозитории (я так понимаю что у вас нет UoW). Ну и в целом посмотрите в сторону row data gateway, я подозреваю что вы что-то подобное и сделали только сложнее.
За сохранение отвечает тот-же репозитроий. Хоть и во круг этого ходят холивары, однако репозиторий это абстракция над хранилищем, поэтому думаю, что методу «сохранить в хранилище» место в репозитории, ну и пока на практике не узнал обратного.
Как разруливаете связи?
AR. Тоесть репозитории и сущности это такая себе абстракция над AR в моем случае.
Что у вас является сущностью?
Взял идею из Symfony. Тоесть у меня есть несколько понятий DTO — класс только с геттерами, который я гоняю между модулями и Сущности, которые в основном находятся в главном модуле Application, и являются практически идентичными как в Symfony.
«я так понимаю что у вас нет UoW»
Да, UoW пока нет, мы только начали пилить проект и подобные штуки я взял на себя смелость внести на этап оптимизации.
Тут проблема в другом. Вам действительно все это надо?
Как показывает практика, если Вы за рамками «бложика» или «сайта-визитки» и требуется постоянно допиливать и обновлять функционал, то подобные вещи весьма кстати.
Хоть и во круг этого ходят холивары
да на самом деле холивары высосаны из пальца. Если у вас есть штука у которой есть метод save и вы используете его как для добавления новой сущности так и для сохранения изменений в уже имеющейся — у вас не очень то и репозиторий, больше походит на table gateway.
Взял идею из Symfony.
являются практически идентичными как в Symfony.
Тут подробнее. У вас там геттеры/сеттеры или полноценная объектая модель, с логикой в сущностях и тд.
Просто ребята из команды доктрины грустят когда их ORM юзают так как показано в документации симфони. Слишком сложная штука для того чтобы использовать тупо как DTO между приложением и базой. Ну и доктрина не является частью симфони.
смелость внести на этап оптимизации.
UoW нужен не для оптимизации, а для того что бы обозначить границу бизнес транзакции и избавиться от необходимости вручную отслеживать изменения всего графа сущностей составляющего агрегат.
Если вы это уже разруливаете руками, я не вижу смысла уже делать UoW. Но тогда мне было бы интересно узнать как вы это разруливаете.
то подобные вещи весьма кстати.
Ну для того что бы объективно оценить надо все же видеть код, просто как по мне у вас слишком уж резкий переход от простого active record к DDD-ной структуре. Да и AR не мешает делать DDD, просто будет больше похоже на row data gateway нежели обычный ar.
Ну тут спорный вопрос, так как данные одной сущности могут быть раскинуты на несколько таблиц. К примеру есть сущность Product, у него есть поля name, description и тп. и данные этих полей могут быть в таблице скажем product_translations (да я пока не решился отойти от этого подхода в пользу json).
Тут подробнее. У вас там геттеры/сеттеры или полноценная объектая модель, с логикой в сущностях и тд.
Видимо не натыкался я на примеры с логикой, но в моем понятии сущность — это класс с геттерами и сеттерами, который ничего не делает, кроме как позволяет предоставить контейнер для данных сущности. Как-то я уже натыкался на весьма серьезную проблему (https://habrahabr.ru/post/316836/) и сущности рассматриваю как обертку над данными и единый формат, который можно гонять по проекту, ну скажем если подменить хранилище, то оперируя сущностями приложение не должно заменить, что что-то пошло там поменялось.
Вообще логика — это понятие скольское, так как сегодня это одно, завтра это другое, в том плане, что у меня были частые ситуации, когда нужно было быстро что-то менять. Например попробовали 1 схему, «не зашла», пробуем другую схему (имеется ввиду работа приложения под бизнес). Поэтому теперь я стараюсь очень аккуратно прятать все за интерфейсами, как можно больше разделать и как можно меньше связывать.
UoW нужен не для оптимизации
Походу его основная задача, это (с) "… Реализация паттерна Unit of Work следит за всеми действиями приложения, которые могут изменить БД в рамках одного бизнес-действия. Когда бизнес-действие завершается, Unit of Work выявляет все изменения и вносит их в БД. ..."
у вас слишком уж резкий переход от простого active record к DDD-ной структуре
Много обжигался. Однако не совсем DDD у меня, скорее просто модульная архитектура и стараюсь следовать SOLID. Сейчас мы пилим API, и возможно версия 2 будет разбита на микросервисы и некоторые даже начнут жить по DDD. Однако сейчас просто нет финансовой возможности позволить «жирных» специалистов. Клиент скорее наймет 5 человек за $5000, чем одного. Поэтому как минимум я весь опыт черпаю из неудачных решений проходя через собственные ошибки.
Ну тут спорный вопрос, так как данные одной сущности могут быть раскинуты на несколько таблиц.
А это уже спрятано за уровень абстракции, так что не столь важно.
но в моем понятии сущность — это класс с геттерами и сеттерами
Рекомендую почитать про такой термин как "анемичная модель". Если коротко — это такая модель которая налагает ту же сложность что и обычная, но не приносит профита поскольку ничего не делает.
А с примерами туго, согласен.
просто модульная архитектура и стараюсь следовать SOLID
Если с тестами и именно юнит тестами, тогда все хорошо)
— DDD
— Entity / VO / DTO
— Repository
и тп.
Ну и Вы про всякие гексагональные архитектуры весьма редко пишите.
точно не хватает статей на PHP про:
Начните с синей книги Эрика Эванса. Там это все тесть. И вы забыли про агрегаты сущностей, bounded context и т.д.
Ну и Вы про всякие гексагональные архитектуры весьма редко пишите.
Я вообще редко пишу… Да и гексагональная архитектура — это один из вариантов построения приложений. Нужно понимать какие характеристики дает та или иная архитектура и думать надо ли вам это или нет.
Простой, современный MVC фреймворк на PHP для разработки сайтов «с нуля»