Миф №3. Нативные компоненты — это реально хорошо.
Нативные компоненты, которые «напрямую» общаются с сервером — это реально хорошо
Дык кто бы спорил.
Вот только есть две, а точнее только одна вещь. Между возможностями клиентского API сервера и актуальными потребностями клиентов сейчас лежит пропасть. Причем — большая. Она и раньше была, причем она была еще обременена багами сервера, но об этом, по ходу, не знали ни одна ни другая сторона. Хотя клиенты, наверное, все таки знали, точнее догадывались. Но вслух не говорили. Думали — а как же по другому-то? По другому же никак… Да я и сам так думал. Со стороны сервера — ну вообщем, только после выхода FB2.5 жизнь стала ярче. Interbase — все в той же глубокой … уверености что «иначе — никак».
Так вот… кстати, о чем это я? А, ну да — о глубокой пропасти. Тут есть два пути.
Первый путь — «мы привязаны к возможностям сервера и по-другому никак». Это оставим без комментариев.
Второй путь — давайте попробуем сделать так, как должно быть. И вот тут возникают задачи для умалишенных. Решение которых порождает код. И в очень большом количестве. И этот код никуда не исчезает, даже если вы статически слинкуетесь с компонентами.
Рано или поздно объем кода, приводящий в соответствие «того что есть, к тому что надо» начнет зашкаливать и те светлые идеи «нативности и легковестности» тихо умирают. А их наследство тупо мешает развиваться компонентами доступа.
Вообще говоря, есть еще один путь — забить на старые сервера. Но это же не интересно. Жизнь, конечно, немного облегчается. Но с новыми серверами (я говорю только про FB2.5), по-любому, скучного программирования не предвидится.
PS. Я специально не стал вдаваться в технические особенности. Могу только сказать, что на реализацию нормальной работы с текстовыми данными (CHAR/VARCHAR, обычные колонки/массивы/блобы) в IBProvider v3 было затрачено больше 6 месяцев. Сюда же входят «пробивание» исправлений ошибок на уровне сервера (в FB2.5) и написание огромного числа тестов. И это — не считая времени, потраченного на подготовку. Тема была закрыта в начале марта 2009. Заявления Вартона о том, что он добавит поддержку UNICODE в свой IBObjects в Q4 2008, вызвали демонический хохот.
PS [2010-10-14]. Я все никак не мог вспомнить последний яркий пример наивности «нативного» подхода. А сегодня вспомнил — «ёлки, да это же операция создания базы данных». Я имею в виду нормальную реализацию этого процесса. Когда не нужно переподключаться и можно задавать параметры, специфичные для конкретного типа сервера (тут фича в чем — про сервер мы узнаем только после того как создадим саму БД …). Она (нормальная реализация) имеет мало чего общего с тем, что можно увидеть, к примеру, в TIBDatabase.CreateDatabase (IBX) или DatabaseImpl::Create (IBPP).
Здесь я торможу поток нахлынувший мыслей (про подключение к базе данных), чтобы в очередной раз бездарно не угробить половину дня 🙂