пятница, 23 мая 2014 г.

Ещё раз ссылка. Мартин Фаулер. Предметно-ориентированные языки программирования

http://namerec.blogspot.ru/2014/04/blog-post.html

Что сказать...

Выглядит - КРУТО и ВНУШАЮЩЕ...

Но!

Я попробовал применить подобную технику в своих проектах.

Что могу сказать?

Мне ЛИЧНО - неудобно.

Очень сложно отлаживать. Break-point'ы ставятся на "всю вязанку" выражения, а не на конкретные строки.

Посему - мне ЛИЧНО - неудобно.

Но выглядит - "ЗАМАНЧИВО".
Автор: на

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

  1. NameRec23 мая 2014 г. в 02:11

    Преимущества подхода, проиллюстрированного примером в том, что он позволяет абстрагироваться от СУБД.
    Главное, чтобы СУБД поддерживала SQL - транслятор учтёт её специфику.
    Код на Pascal, описывающий SQL, очень похож на тот SQL, который требуется создать. В результате, такой код писать довольно удобно.
    Далее, формируемый код проходит определённую верификацию в момент компиляции: поскольку создаются интерфейсы - с ними просто невозможно сделать то, чего они не предоставляют. С другой стороны, если SQL записан в строке, там можно написать всё, что угодно - ошибка проявится при попытке выполнить такую строку.

    Относительно отладки. Я действительно не считаю эту проблему существенной по ряду причин.
    В случае, если что-то работает "не так", при локализации проблемы сначала проще верифицировать полученную структуру. Например, можно получить строковое представление полученного запроса в виде JSON/XML или, даже готового SQL. После этого уже смотреть на то, что выглядит не так, как ожидалось и расставлять точки останова.

    Очень сложно отлаживать. Break-point'ы ставятся на "всю вязанку" выражения, а не на конкретные строки.
    -- В целях отладки, если очень хочется, можно всегда разорвать fluent-цепочку. В таком случае можно заходить в методы интерфейсов привычным способом.
    Ну и по опыту (я в комментариях это отметил) - отлаживать формирование структуры запроса приходится очень и очень редко.

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

Подписаться на: Комментарии к сообщению (Atom)