И всё-таки, если уйти от перехода на личности и попробовать совместить позиции.
Я считаю, что работа с БД в этом фреймворке организована неправильно
Претензий у меня основных две.
Первая - чисто инструментального плана. Вполне исправима. Уровень работы с SQL не доделан, не имеет необходимого функционала. В частности оттого, что перенимает все родовые недостатки PDO.
Авторы PDO наивно полагают, что сделали удобный класс для работы с БД. Хотя на самом деле никакого удобства в нём нет, как нет и множества необходимых вещей.
Пример такого необходимого функционала - плейсхолдер для оператора SET. при отсутствии его код приложения превращается в адский треш с кишками SQL-я.
Исправлять эти недостатки предлагается уровнем выше, в классе-прототипе. Это я считаю в корне неправильным. Я считаю, что каждый уровень должен заниматься своим делом. SQL должен заниматься SQL-ем. ОРМ - предоставлять базовые методы для работы с объектами.
Вторая претензия - архитектурная.
Я считаю, что в заявлениях про фреймворк есть непреодолимое противоречие: расширяемость vs. хардкод SQL. Если мы оставляем себе такую возможность - значит, о расширяемости придётся забыть. Надо выбрать что-то одно.
Решение я вижу здесь только одно - или трусики надеть, или крестик снять:
- либо мы не стесняемся хардкода и используем его на уровне приложения.
- либо мы лепим полноценный орм, который потом титаническими усилиями можно будет расширить на прозрачную смену хранилища.
getWhere в коде приложения - это фиговый листок. Это ТОТ ЖЕ САМЫЙ НЕРАСШИРЯЕМЫЙ хардкод SQL, который просто засунул голову в песок.
Я - за честность. Если мы пишем в коде SQL - пусть это будет честный SQL.
Если у меня всё равно SQL, то я предпочитаю цельным куском, а не расчленёнку, когда в приложении видны только ноги, а голова скрывается где-то в глубоко в недрах приложения.
Я считаю, что работа с БД в этом фреймворке организована неправильно
Претензий у меня основных две.
Первая - чисто инструментального плана. Вполне исправима. Уровень работы с SQL не доделан, не имеет необходимого функционала. В частности оттого, что перенимает все родовые недостатки PDO.
Авторы PDO наивно полагают, что сделали удобный класс для работы с БД. Хотя на самом деле никакого удобства в нём нет, как нет и множества необходимых вещей.
Пример такого необходимого функционала - плейсхолдер для оператора SET. при отсутствии его код приложения превращается в адский треш с кишками SQL-я.
Исправлять эти недостатки предлагается уровнем выше, в классе-прототипе. Это я считаю в корне неправильным. Я считаю, что каждый уровень должен заниматься своим делом. SQL должен заниматься SQL-ем. ОРМ - предоставлять базовые методы для работы с объектами.
Вторая претензия - архитектурная.
Я считаю, что в заявлениях про фреймворк есть непреодолимое противоречие: расширяемость vs. хардкод SQL. Если мы оставляем себе такую возможность - значит, о расширяемости придётся забыть. Надо выбрать что-то одно.
Решение я вижу здесь только одно - или трусики надеть, или крестик снять:
- либо мы не стесняемся хардкода и используем его на уровне приложения.
- либо мы лепим полноценный орм, который потом титаническими усилиями можно будет расширить на прозрачную смену хранилища.
getWhere в коде приложения - это фиговый листок. Это ТОТ ЖЕ САМЫЙ НЕРАСШИРЯЕМЫЙ хардкод SQL, который просто засунул голову в песок.
Я - за честность. Если мы пишем в коде SQL - пусть это будет честный SQL.
Если у меня всё равно SQL, то я предпочитаю цельным куском, а не расчленёнку, когда в приложении видны только ноги, а голова скрывается где-то в глубоко в недрах приложения.
