Вдумчивая дискуссия о технологических тонкостях АКА очередной ООП***ч

  • Автор темы Автор темы Chusha
  • Дата начала Дата начала
Ну вообще да, но не совсем, т.к. сам интерфейс явно декларирован.
 
В PHP такую вещь, кстати, ничего не мешает реализовать: и проблем с обратной совместимостью нет, и проверка класса на соответствие интерфейсу в любом случае 1 раз происходит, т.е. проблем с оптимизацией не возникает. (-:
 
тебе другие уже сто раз ответили. я с ними согласен

дело в том что такая задача никогда не стоит. всегда на самом деле два варианта - либо говносайт (или коробочная cms что суть то же) для шаред хостинга (без вариантов мыскль-муисам, до примитивного уровня которого действительно можно низвести любую субд - но никому это не надо), либо какое-то приложение - для которого берем ту субд, которая нам больше подходит.
 
Chusha
Вначале ты начни отвечать на ответы, а не заходить кидать бредовые реплики разжигающие серца ламеров и стоять в сторонке и ржать. Тролли тут не долго задерживаются, потому что средний айку тут выше чем у древесных троллей.

Так что адью, наверна?

fixxxer
Don't feed forum troll
 
Как по мне смысл оберток не только в абстрагировании от СУБД, но и в удобочитаемости кода. Мало-мальски сложный запрос не может быть написан обной строкой. В зависимости от некоторых условий меняются условия выборки, меняются выбираемые поля, поля для сортировки. В результате текст SQL-запроса может размазываться по методу, а то и по нескольким, и целосного восприятия его не будет.

Ведь приятней же читать
PHP:
$music->search()->byArtist('Shopen')->fromYear(1830)->toYear(1840)->paginate(2);
 
Chusha
Здесь, порой, народ конечно довольно категорично высказывается...
Но предположение
"зачем мы создаём эти обёртки? Наверное для того, чтобы абстрагироваться от конкретного хранилища"
действительно не очень похоже на реальность. Даже с большой натяжкой.
В подавляющем большинстве (по моему опыту на сегодня вообще 100%) база НЕ меняется.
А обертка служит исключительно для удобства. Авто эскейпа и т.п.
Я даже не стесняюсь иногда сделать для этих целей просто класс со всеми статическими методами и использовать имя этого класса просто как неймспейс.
Хотя безусловно если вдруг, когда-нибудь, придётся менять БД, то само существование такой обёртки значительно упростит такой переход.
 
Давайте не будем путать DBAL и Query Builder :)
Одно другому не помеха. Взглянуть даже на елементарные лимиты.

Firebird:
PHP:
 SELECT FIRST 10 SKIP 20 column1, column2, column3 FROM foo

MySQL
PHP:
 SELECT column1, column2, column3 FROM foo LIMIT 20, 10
или как в Postgres

Postgres
PHP:
 SELECT column1, column2, column3 FROM foo LIMIT 10 OFFSET 20

Как абстрагироваться от СУБД без инкапсуляции лимитов в Query Builder?
 
а если вспомнить оракл, то там вообще лимита нет)
 
Кажется я внес конфуз. Я имел в виду DataBase Access Layer. Про абстрагирование от СУБД я уже сказал что думаю. Ну вот кстати хороший пример - напиши ка аналог для MSSQL:)
 
Кажется я внес конфуз. Я имел в виду DataBase Access Layer. Про абстрагирование от СУБД я уже сказал что думаю. Ну вот кстати хороший пример - напиши ка аналог для MSSQL:)
Тоесть ты хочешь сказать, что для MSSQL нельзя инкапсулировать лимиты? Хоть и выйдет трехетажно, но как минимум есть два способа - через TOP, как это сделано в ZF, и через ROW_NUMBER() для MSSQL 2005. Понятное дело, что все всунуть оптимально в единый интерфейс весьма сложно, но , так сказать, сами виноваты. Хотите использовать MSSQL, используйте родные для него ASP.NET и ODBC
 
а оно разве не подохло? у меня офсайт даже не грузится.
 
Сверху