Библиотека совсем несвязана с тем, чтобы управлять данными пользователя, ну по крайней мере сейчас. То есть, функционал библиотеки завязан лишь на том, чтобы хранить структуру всего. А значения, которые вы получаете в Entity, они никак не изменяются, только лишь проходят все проверки, дальше Entity данные никуда не проникнут, только если вы их оттуда вытащите. Безусловно, сейчас в код нужно лезть, но ведь в рамках этой демки, хочу показать то, что вы в коде, имеете верные данные, Вы не добавляете массу дополнительных условий чтобы проверить каждое значение и не пишите циклы для этого (А то что в базе хранится структура, только даёт возможность вам быть уверенным в том, что структура модельки и базы совпадают, и править это можно удобно в одном месте, в интерфейсе).
Спасибо за ответ. Всё что касается доступности отдельных файлов/папок действительно есть недочёты. Composer был добавлен уже перед тем, как опубликовать демку для подключения классов. Зачем делать подключение function.php когда есть композер — это очень точное замечание, и оно меня заставило улыбнуться, много подключено вот только для того, чтобы работало, и я мог предоставить библиотеку в обозрение. А по поводу того, какая была идея добавлю, конечно, несколько слов.
Созданные в модели параметры, имеют обязательный набор свойств. Значение, которое хранится в Entity обязательно соответствует всем вынесенным требованиям. К примеру, если вы указали, что в модели есть параметр «email», который обязателен, является строкой и не превышает 15 символов, и вы пытаетесь создать Entity на основе этой модели, вот передавайте что угодно, но пока значение не пройдёт эту валидацию, вы будете получать ошибку. Таким образом, мы получаем тот вид и набор данных, который нам нужен, не какой-либо другой, другой не годится. Кроме вот этой идеи, ещё воплощено то, что мы можем связать модель и таблицу в БД (а таблица и колонки будут созданы вместе с моделью в интерфейсе). Мы таким образом сводим к минимуму дополнительные проверки всех данных и знаем какие параметры должны быть записаны в базу, а какие нет.
Ещё пример, вызываем какой-либо API метод, и в ответе ждём параметр «token» (обязателен, строка, ...), и создаём определённую модель для того, чтобы из полученного ответа создать конкретную Entity, если Entity создалась успешно, значит и значения в ней точно верны, ну а если нет, то одной из причин может быть то, что в теле ответа нет совсем параметра «token», а может быть значение пришло null…
В общем, я пытался не давать таких примеров в статье, чтобы каждый мог сам подумать, как это можно использовать.
Созданные в модели параметры, имеют обязательный набор свойств. Значение, которое хранится в Entity обязательно соответствует всем вынесенным требованиям. К примеру, если вы указали, что в модели есть параметр «email», который обязателен, является строкой и не превышает 15 символов, и вы пытаетесь создать Entity на основе этой модели, вот передавайте что угодно, но пока значение не пройдёт эту валидацию, вы будете получать ошибку. Таким образом, мы получаем тот вид и набор данных, который нам нужен, не какой-либо другой, другой не годится. Кроме вот этой идеи, ещё воплощено то, что мы можем связать модель и таблицу в БД (а таблица и колонки будут созданы вместе с моделью в интерфейсе). Мы таким образом сводим к минимуму дополнительные проверки всех данных и знаем какие параметры должны быть записаны в базу, а какие нет.
Ещё пример, вызываем какой-либо API метод, и в ответе ждём параметр «token» (обязателен, строка, ...), и создаём определённую модель для того, чтобы из полученного ответа создать конкретную Entity, если Entity создалась успешно, значит и значения в ней точно верны, ну а если нет, то одной из причин может быть то, что в теле ответа нет совсем параметра «token», а может быть значение пришло null…
В общем, я пытался не давать таких примеров в статье, чтобы каждый мог сам подумать, как это можно использовать.
Все ваши замечания приняты во внимание. Спасибо!