Одна из наших команд недавно начала работу над проектом с классической service-oriented архитектурой (SOA): back-end ядро с выходом на "внешний мир" через Web-сервисы, и раздельные Web- и Windows-клиенты для разных групп пользователей. А поскольку я курирую в компании вопросы, связанные с архитектурой и технологическими решениями, то предложил их program manager'у свою посильную помощь в консультациях по разработке бизнес-требований и архитектуре.
В ходе совещания с представителями команды всплыл интересный факт - хотя проект еще фактически на стадии анализа предметной области и выявления бизнес-требований с бизнес же use cases'ами, уже больше месяца пишется код. Я сначала подумал, что речь идет о прототипировании, что было бы вполне уместно. Но я ошибался - оказалось, что команда решила не терять времени и свободными ресурсами пока создать вспомогательные каркасы (frameworks) для доступа к данным и организации пользовательского интерфейса.
Разумеется, я посоветовал парням не изобретать велосипед, а воспользоваться готовыми блоками из Enterprise Library, тем более что это бесплатно и поставляется непосредственно Microsoft, а не некоей третьей стороной. Надо отдать должное Solutions Architect команды, который совершенно правильно вспомнил акроним CAB (Composite UI Application Block).
Но вот тут-то и началось самое интересное. Заинтересованность команды быстро сменилась настороженностью - а вдруг тот же CAB окажется недостаточно гибким, а вдруг мы наступим на какие-нибудь грабли и придется разбираться с массой чужого нетривиально написанного кода? И я понимаю их реакцию - головой отвечать за проект им, сроки - не разгуляешься, а опыта в использовании Enterprise Library никакого. Поэтому настаивать я не стал, лишь посоветовав Dev Lead'у детальнее посмотреть на CAB как на решение, созданное профессионалами высокого класса в противовес собственному framework'у, который пишет хоть и толковый, но начинающий программист.
А потом задумался: Замкнутый круг ведь какой-то. Чтобы принять обоснованное решение об использовании Enterprise Library, ее надо достаточно хорошо знать. А для этого нужен практический опыт, который не получишь, не попробовав Enterprise Library на реальном, серьезном проекте.
Выход я пока вижу только один - искать готовые и создавать собственные примеры нетипичных сценариев использования Application Blocks и их тонкой настройки, чтобы архитекторы и Dev Lead'ы могли воочию убедиться - да, это работает, да, это возможно.
Может, кто-то еще поделится какими идеями или опытом внедрения Enterprise Library?