Использование блоков приложений Microsoft

Question

Я не много занимался программированием на .NET, но я изучил несколько блоков приложений, опубликованных группой Microsoft Patterns and Practices. Мне было интересно, как они обычно используются:

• Связано напрямую с приложениями
• Источник добавлен в приложения и построен с ними, возможно, с некоторыми настройками
• Пример кода, используемого в качестве ссылки при написании кода для конкретного приложения

Я уверен, что все эти три вида использования являются общими, но каковы наиболее типичные схемы использования?

Есть ли несколько отдельных блоков приложений, которые используются всеми?

Примечание. Этот вопрос относится к блокам приложений корпоративной библиотеки ИЛИ Home Grown Framework? .

Answer 1

Я широко использовал корпоративную библиотеку Microsoft. Как правило, они никогда не должны включаться в ваш проект, если это возможно. Дополнительная стоимость компиляции может быть большой. Кроме того, нет причин иметь исходный код в вашем проекте для использования классов. Во время кодирования вы по-прежнему будете обладать интеллектом, если добавите ссылку на библиотеки DLL в свои проекты. Также желательно избегать множественных кодовых баз, плавающих вокруг вашей среды разработчика. Если вам нужно настроить классы, откройте их в их собственном решении и оставьте одну версию активной. Конечно, я всегда настоятельно рекомендую использовать контроль версий (VSS или Subversion) на случай, если вам понадобится откатить изменения.

Существуют также альтернативы классам Microsoft с открытым исходным кодом, которые обычно лучше кодируются (например, Log4Net, nUnit и т. Д.). Код Microsoft имеет тенденцию быть раздутым и неэффективным.

Answer 2

Я пробовал несколько блоков приложений Enterprise Lib 3.1 (май 2007 г.) и вот несколько комментариев:

Блок приложения кэширования: менее интересный, чем System.Web.Caching в простых сценариях (например, кэширование в памяти) Обработка и регистрация исключений: слишком сложная. NLog или Log4Net - лучшие решения.

Я посмотрел на другие блоки, но они не подходили для наших проектов.

Наконец мы полностью удалили EntLib, потому что было больно настраивать ... Я бы посоветовал вам действительно рассмотреть менее монолитное решение, чем EntLib.

Answer 3

Мы просто помещаем двоичные файлы EntLib 3.1 в глобальный кеш сборок и добавляем ссылки в наши проекты. Мы обычно используем только каркас журналирования.

Answer 4

Я обычно помещаю источник в свой проект, и тогда я могу лучше понять смысл (и лучше понять их). Я не склонен настраивать их вообще, хотя. Мне нравится иметь их в наличии, чтобы я мог просто распространять их в любое время.

Answer 5

Я думаю, что наиболее удобный способ - добавить блоки App \ EntLib в качестве элементов решения. Таким образом, они не будут перекомпилироваться каждый раз, когда вы создаете свой проект (они вообще не будут участвовать в процессе сборки), и вы можете легко получить доступ к их исходному коду \ установить точку останова и т. Д.

Answer 6

Мы используем блоки, добавляя ссылки на библиотеки DLL, следя за тем, чтобы «копировать локально» было установлено так, чтобы они были развернуты вместе с приложением в папке «bin» приложения. Это означает, что нам не нужно возиться с GAC - намного проще!

При отладке Visual Studio по-прежнему может входить в исходный код, даже если он не включен непосредственно в ваш проект, если у вас где-нибудь есть исходный код EntLib на жестком диске. Он предложит вам указать местоположение при первом использовании и запомнит его после этого.

В настоящее время мы используем блоки Caching, Exception и Logging. Мы еще не думали об одном случае использования для остальных.