О выборе инструментов.

Октябрь 23, 2008 – 10:21 пп

При разработке более-менее крупных проектов всегда (а всегда ли?) стоит вопрос об использовании средств поддержки разработки, библиотек и фреймворков. Даже при реализации обычных задач использование стандартных библиотек и протоколов в последствии может вылезти боком. Недавно имела место такая ситуация.

Последние 4-5 месяцев я занимался реализацией ядра системы сервисов для внутренних нужд предприятия. Проект и все сопутствующие ему программы и сервисы реализовывались на платформе Python с использованием формата передачи данных JSON, потому возможности динамического языка использовались на полную катушку. Недавно пришлось реализовывать клиентскую библиотеку к нашей системе для проекта использующего .Net. Само по себе ничего сложного в этом не было – вся динамика python была сымитирована использованием NullableTypes (на тот случай если передаваемая структура является полиморфной и не все поля присутствуют при каждом ответе/запросе), проблемы начались когда пришлось entity классы этой библиотеки передавать через внутренние web-сервисы, которые в .net реализованы с использованием протокола SOAP. Выяснилось, что реализация протокола SOAP в .Net framework не поддерживает передачу полиморфных структур или NullableTypes. Для этого было сделано решение, на мой взгляд представляющее собой костыль – были написаны две обёртки (со стороны клиента и web-сервиса .net проекта), которые скрывали сериализацию entity классов в бинарный формат. Вот и получилось, что классы, которые успешно передавались от python-сервисов .net web-сервисам для передачи клиенту приходится сериализовывать два раза (класс -> бинарная сериализация -> soap-сериализация).

К чему бы все это? Это к вопросу о выборе библиотек и протоколов. Даже во время реализации небольших проектов могут возникать проблемы из-за использования стандартных решений. Как уже написано выше, для передачи данных к/от python-сервисам были использован формат сериализации данных JSON. Так как фреймворков для построения rpc-сервисов на основе JSON нет, пришлось реализовывать все с нуля на основе web-сервера CherryPy и наших внутренних разработок.

Это не призыв к отказу от фреймворков. Наоборот, лично мне очень нравится Django, их необходимо использовать, но там где это необходимо.



  1. Комментарии:

  2. >>но там где это необходимо
    Это уж бесспорно )

    Плюс все эти высокоуровневые навороты даже без очевидной избыточности ощутимо снижают производительность конечного продукта – повышая, надо понимать, производительность отдельно взятого разработчика.

    * Помнится, при разработке entities-средств для .net девтим ставил задачу примерно так: “это не должно лажать по производительности _больше чем в 3 раза_”. И т.п.

    (btw: у тебя openid меня не пускает)

    By CGVictor on Окт 23, 2008

  3. Все-таки без ORM разного калибра (rich, anemic), как правило, довольно сложно поддерживать код. Естественно, надо представлять себе сложность и ресурсоемкость решения. Например, часто при использовании sqlalchemy/elixir приходилось, наравне с использованием высокоуровневого кода, писать чуть ли не sql, но все-равно в терминах sqlalchemy, т.к. в таком случае поддерживать код становилось гораздо проще, а по эффективности ни чем не отличалось, если бы писался напрямую в СУБД.

    (PS: openid вроде починил)

    By Roinet on Окт 24, 2008

  4. Спасибо! а еще посты на эту тему будут?

    By Caurnant on Дек 22, 2008

  5. Будут. Правда совсем времени нет писать посты.

    By Roinet on Дек 22, 2008

Добавить комментарий: