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

Question

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

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

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

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

Примечание:Этот вопрос связан с, но не то же самое, что Блоки приложений корпоративной библиотеки ИЛИ собственная разработка?.

Answer 1

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

Answer 2

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

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

Answer 3

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

Кэширование прикладного блока:Менее интересно, чем System.Web.Chaching в простых сценариях (например, кэширование в памяти) Обработка и регистрация исключений:Чрезмерно сложно.NLog или Log4Net — лучшие решения.

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

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

Answer 4

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

Answer 5

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

Answer 6

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

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

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