accido
Новичок
Проблема: высокоуровневая прослойка над ДБ мешает:
а) использовать язык запросов на полную мощность;
б) использовать драйвер БД в ЯП на полную мощность;
в) мешает переходить на различные БД( типа sql => noSql );
г) ORM(строка-обьект) противоречит сущности ООП, так как создает левый функционал для работы с БД, в то время как,
следуя ООП нужно представить сами таблицы БД классами, для того чтобы отобразить сущность БД в предметную область приложения. Тогда в следствии этого тождественного отображения мы можем работать с этими классами как с БД. Эти классы тоже являются моделями, потому что относятся к БД. Хотя работу самой БД мы не можем увидеть, но она реально существует, подобный пример - это электричество. То есть следуя ООП следует описать БД тождественным отображением классов.
Поэтому был придуман новый паттерн( по крайней мере пока не видел похожего ) для взаимодействия с БД
в приложении. За основу был положен паттерн Repository, но с отличиями:
доступ в репозиторий осуществляется не напрямую, а через контроллер операции. Репозитории - это обычные модели, которые отображают БД в предметную область приложения. Репозитории работают через драйвер-модель, который отображает драйвер БД в рабочую область, это тоже следует из принципов ООП.
Пример этого можно увидеть тут https://bitbucket.org/accidos/accido-fw. Реализовано подключение драйвера mysqli через его рабочий класс goDB.
П.С. В доктрине 2 появился паттерн репозиторий, но так как все остальное по-прежнему осталось - то это не совсем то. Просто один маленький шаг для доктрины ...
П.П.С. Возможно перенесу эти концепции на симфони 2, чтобы использовать ее без доктрины и твига( в сущности и то, и то просто ШАБЛОНИЗАТОРЫ данных). Нужно решить реально нужны ли роутеры, хелперы и прочие вспомогательные конструкции. Можно также использовать зенд 2. И там, и там есть готовые менеджеры ивентов. Рассматривается еще куча ФВ типа коханы, фуэла, yii, но все таки больше смотрю на симфони 2.
а) использовать язык запросов на полную мощность;
б) использовать драйвер БД в ЯП на полную мощность;
в) мешает переходить на различные БД( типа sql => noSql );
г) ORM(строка-обьект) противоречит сущности ООП, так как создает левый функционал для работы с БД, в то время как,
следуя ООП нужно представить сами таблицы БД классами, для того чтобы отобразить сущность БД в предметную область приложения. Тогда в следствии этого тождественного отображения мы можем работать с этими классами как с БД. Эти классы тоже являются моделями, потому что относятся к БД. Хотя работу самой БД мы не можем увидеть, но она реально существует, подобный пример - это электричество. То есть следуя ООП следует описать БД тождественным отображением классов.
Поэтому был придуман новый паттерн( по крайней мере пока не видел похожего ) для взаимодействия с БД
в приложении. За основу был положен паттерн Repository, но с отличиями:
доступ в репозиторий осуществляется не напрямую, а через контроллер операции. Репозитории - это обычные модели, которые отображают БД в предметную область приложения. Репозитории работают через драйвер-модель, который отображает драйвер БД в рабочую область, это тоже следует из принципов ООП.
Пример этого можно увидеть тут https://bitbucket.org/accidos/accido-fw. Реализовано подключение драйвера mysqli через его рабочий класс goDB.
П.С. В доктрине 2 появился паттерн репозиторий, но так как все остальное по-прежнему осталось - то это не совсем то. Просто один маленький шаг для доктрины ...
П.П.С. Возможно перенесу эти концепции на симфони 2, чтобы использовать ее без доктрины и твига( в сущности и то, и то просто ШАБЛОНИЗАТОРЫ данных). Нужно решить реально нужны ли роутеры, хелперы и прочие вспомогательные конструкции. Можно также использовать зенд 2. И там, и там есть готовые менеджеры ивентов. Рассматривается еще куча ФВ типа коханы, фуэла, yii, но все таки больше смотрю на симфони 2.
