суббота, 30 ноября 2013 г.

По-моему - "риторический вопрос"

http://delphi2010.ru/firedac-sqlite-encoding/?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+Delphi2010ru+%28Delphi+2010.ru%29

 "Во многих СУБД про кодировку строк нужно помнить ещё перед установкой самой СУБД.
Кстати это вот один из злейших недостатков датасетов – если в дизайнере насоздавать поля, а потом в БД чего-то поменять, то синхронизировать это с исходником… мягко говоря неудобно.
Меня вот удивляет, почему ещё никто не предлагает (пусть даже платных) решений-альтернатив датасетов? Или они есть, но малоизвестны, потому-что все привыкли к датасетам?"

По мне, так по-моему - всё объясняется "консерватизмом" и "ленью".

Про TDataSet у меня вообще есть "свой взгляд", но я его пока - "оставлю при себе".

1 комментарий:

  1. А я бы за использование датасетов по всему проекту программистов наказывал физически, поскольку оно приводит к образованию нечитаемого и не поддающегося анализу макаронного кода. Достань нужные данные, разложи по своим структурам в свои контейнеры, сделай с ними что нужно, положи их обратно в БД - по-моему вот это здравый подход, применяемый во множестве платформ и со множеством языков. Один только Фаулер напредлагал столько "решений-альтернатив датасетам" - что мама не горюй. А если уж совсем не нравится реализация TDataSet и способ его хранения в dfm - можно полдня покурить мануалы и написать свою вундервафлю для доступа к данным в БД с использованием API СУБД / ODBC / бог знает еще чего там.
    А в дельфях народ все какую-то "серебряную пулю" ищет, желательно упакованную в компонент и доступную для "бросания на форму" из "палитры". И таки да - все объясняется консерватизмом и ленью.

    ОтветитьУдалить