Комментарии 11
Попытался поставить, но не заработало. Полагаю, потому что APIURL захардкожен (http://grigorov.com/abi/index.php)
Немного не понял идею. Я так понимаю что идея просто в визуализации диаграммы классов? Тогда почему «библиотека», если завязка на полный http стек?
Решил посмотреть код, разобраться. Понимаю, что посыл статьи не в «библиотеке», а в идее, но всё же…
Решил посмотреть код, разобраться. Понимаю, что посыл статьи не в «библиотеке», а в идее, но всё же…
Чуть про исходники
1) vendor в git не хранится никогда
2) PSR-1/2/12 нету, что печалит
3) vendor и все ситемные файлы доступны из под http, включая конфиги и прочее. Понимаю что демка, но это же основы безопасности.
4) Синглтон, особенно для конфигов — это печально.
5) Зачем делать require для functions.php, когда есть композер?
6) Почему functions в глобальном пространстве и без проверок на существование?
7) Ну и вообще: github.com/daniilgrigorovabi/abimodelpattern/blob/master/abi/src/classes/database/drivers/Mysql_Driver.php#L122
Я бы просто постеснялся выкладывать подобные исходники, написанные по всем канонам того, как писать не стоит. Особенно метка goto на 256ой строке доставляет =))))
2) PSR-1/2/12 нету, что печалит
3) vendor и все ситемные файлы доступны из под http, включая конфиги и прочее. Понимаю что демка, но это же основы безопасности.
4) Синглтон, особенно для конфигов — это печально.
5) Зачем делать require для functions.php, когда есть композер?
6) Почему functions в глобальном пространстве и без проверок на существование?
7) Ну и вообще: github.com/daniilgrigorovabi/abimodelpattern/blob/master/abi/src/classes/database/drivers/Mysql_Driver.php#L122
Я бы просто постеснялся выкладывать подобные исходники, написанные по всем канонам того, как писать не стоит. Особенно метка goto на 256ой строке доставляет =))))
Спасибо за ответ. Всё что касается доступности отдельных файлов/папок действительно есть недочёты. Composer был добавлен уже перед тем, как опубликовать демку для подключения классов. Зачем делать подключение function.php когда есть композер — это очень точное замечание, и оно меня заставило улыбнуться, много подключено вот только для того, чтобы работало, и я мог предоставить библиотеку в обозрение. А по поводу того, какая была идея добавлю, конечно, несколько слов.
Созданные в модели параметры, имеют обязательный набор свойств. Значение, которое хранится в Entity обязательно соответствует всем вынесенным требованиям. К примеру, если вы указали, что в модели есть параметр «email», который обязателен, является строкой и не превышает 15 символов, и вы пытаетесь создать Entity на основе этой модели, вот передавайте что угодно, но пока значение не пройдёт эту валидацию, вы будете получать ошибку. Таким образом, мы получаем тот вид и набор данных, который нам нужен, не какой-либо другой, другой не годится. Кроме вот этой идеи, ещё воплощено то, что мы можем связать модель и таблицу в БД (а таблица и колонки будут созданы вместе с моделью в интерфейсе). Мы таким образом сводим к минимуму дополнительные проверки всех данных и знаем какие параметры должны быть записаны в базу, а какие нет.
Ещё пример, вызываем какой-либо API метод, и в ответе ждём параметр «token» (обязателен, строка, ...), и создаём определённую модель для того, чтобы из полученного ответа создать конкретную Entity, если Entity создалась успешно, значит и значения в ней точно верны, ну а если нет, то одной из причин может быть то, что в теле ответа нет совсем параметра «token», а может быть значение пришло null…
В общем, я пытался не давать таких примеров в статье, чтобы каждый мог сам подумать, как это можно использовать.
Все ваши замечания приняты во внимание. Спасибо!
Созданные в модели параметры, имеют обязательный набор свойств. Значение, которое хранится в Entity обязательно соответствует всем вынесенным требованиям. К примеру, если вы указали, что в модели есть параметр «email», который обязателен, является строкой и не превышает 15 символов, и вы пытаетесь создать Entity на основе этой модели, вот передавайте что угодно, но пока значение не пройдёт эту валидацию, вы будете получать ошибку. Таким образом, мы получаем тот вид и набор данных, который нам нужен, не какой-либо другой, другой не годится. Кроме вот этой идеи, ещё воплощено то, что мы можем связать модель и таблицу в БД (а таблица и колонки будут созданы вместе с моделью в интерфейсе). Мы таким образом сводим к минимуму дополнительные проверки всех данных и знаем какие параметры должны быть записаны в базу, а какие нет.
Ещё пример, вызываем какой-либо API метод, и в ответе ждём параметр «token» (обязателен, строка, ...), и создаём определённую модель для того, чтобы из полученного ответа создать конкретную Entity, если Entity создалась успешно, значит и значения в ней точно верны, ну а если нет, то одной из причин может быть то, что в теле ответа нет совсем параметра «token», а может быть значение пришло null…
В общем, я пытался не давать таких примеров в статье, чтобы каждый мог сам подумать, как это можно использовать.
Все ваши замечания приняты во внимание. Спасибо!
Хм, т.е. грубо говоря — это некая CMS для ECS?
Хотя нет, глупость сказал. В ECS поведения накидываются извне и не отображают предметную область. А тут просто редактор моделей.
Т.е. из плюсов — визвиг редактор всего. Из минусов — всё равно придётся в код лезть, т.к. в таком виде они представляют из себя обычные анемичные модели, или даже DAO с инвариантами. Хм, получается в этом и задумка? Обычный редактор DAO записей в БД?
Т.е. из плюсов — визвиг редактор всего. Из минусов — всё равно придётся в код лезть, т.к. в таком виде они представляют из себя обычные анемичные модели, или даже DAO с инвариантами. Хм, получается в этом и задумка? Обычный редактор DAO записей в БД?
Библиотека совсем несвязана с тем, чтобы управлять данными пользователя, ну по крайней мере сейчас. То есть, функционал библиотеки завязан лишь на том, чтобы хранить структуру всего. А значения, которые вы получаете в Entity, они никак не изменяются, только лишь проходят все проверки, дальше Entity данные никуда не проникнут, только если вы их оттуда вытащите. Безусловно, сейчас в код нужно лезть, но ведь в рамках этой демки, хочу показать то, что вы в коде, имеете верные данные, Вы не добавляете массу дополнительных условий чтобы проверить каждое значение и не пишите циклы для этого (А то что в базе хранится структура, только даёт возможность вам быть уверенным в том, что структура модельки и базы совпадают, и править это можно удобно в одном месте, в интерфейсе).
Это уже было в симпсонах битриксе
Слабые стороны:
- Нет версионности, миграций как таковых.
- Легко потерять данные.
- Классы фактически не генерируются, атрибутов не будет в autocomplete idea, a c php 56 даже не будут проверяться на isset/empty
- psr/тесты...
Практически весь функционал библиотеки реализован в кодогенераторах популярных фреймворков.
У меня есть критика, только я вам ее не скажу. Предоставляю вашему воображению создать правильную картинку.
foreach($_POST as $function_name => $parameters) {
if (function_exists($function_name)) {
$result = $function_name($parameters);
...Жесть какая) Спрячьте эту поделку и не показывайте никому.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Операция «Ы» и новая библиотека ABI