Преимущества и недостатки использования Enterprise Library

Основное преимущество блока приложения базы данных состоит в том, что он упрощает создание кода, не зависящего от базы данных. Разработчик взаимодействует в основном с общими объектами Database и DbCommand, а не, например, с SqlConnection, SqlCommand и т. д. Таким образом, переключение на другую базу данных (например, Oracle) становится более осуществимым. В зависимости от потребностей вашего бизнеса, это может быть определенным преимуществом. EntLib также осторожно подталкивает разработчика к использованию DbParameter для параметров запроса, что снижает риск атак путем внедрения кода SQL.

Как упоминалось в другом постере, блок приложения данных несколько более высокого уровня, чем простые классы ADO.NET, поэтому для выполнения той же задачи обычно требуется меньше строк кода.

С моей точки зрения, наиболее полезными являются блоки данных, исключений и протоколирования. Exception и Logging вместе позволяют очень легко регистрировать исключения (дух) в ряде мест и в различных форматах. Например, они могут поместить всю запись журнала исключений, включая трассировку стека, в журнал событий Windows, что упрощает диагностику проблемы.

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

Моя команда провела оценку корпоративной библиотеки Microsoft Patterns and Practices около 2 лет назад в рамках модернизации нашей линейки продуктов. Единственной частью, которую мы в итоге использовали, был блок базы данных. Мы даже обернули это в некоторые классы, которые могли создавать экземпляры, чтобы мы могли смоделировать DAL для модульного тестирования; блок кода Microsoft использовал статические вызовы для работы с базой данных. Я не уверен, интегрировала ли Microsoft какой-либо материал LINQtoSQL или Entity Framework в блок db. Я бы не решился использовать блок db сейчас, если бы он не использовал один из них.

Что касается ведения журнала, мы обнаружили, что Log4Net является гораздо более надежным и гибким решением, которое журнал Майкрософт. Мы пошли с этим для наших потребностей в регистрации.

Для обработки исключений мы создали собственный. Код Microsoft не обрабатывал случаи удаленного взаимодействия, которые мы хотели обработать, и, поскольку мы использовали стороннюю структуру ведения журналов, имело смысл написать собственную библиотеку исключений и интегрироваться с ней. Я обнаружил, что некоторый уровень интеграции фреймворка ведения журнала в фреймворк исключений может быть очень полезным. Мы написали несколько легких классов-оболочек вокруг Log4Net и вызвали их из нашей регистрации исключений, чтобы не вводить зависимости от Log4Net.

В дополнение к пунктам, упомянутым Полом о блоке приложения данных, я также хотел бы отметить, что, по моему опыту, блок приложения данных также обеспечивает гораздо БЫСТРЫЙ способ написать необходимый код базы данных с помощью существующих помощников. Я использую его из-за его последовательного внешнего вида и скорости разработки.

Выбор не использовать EF для меня связан с ограничениями, которые есть у меня в моей среде, которые требуют, чтобы приложения обрабатывали миллионы транзакций в час. Это объем обработки в среде Telco.

Использовать EF или нет, полностью зависит от вашей среды и выбора (при условии, что вы знаете ограничения выбранной технологии). Если ваша система не требует таких высоких нагрузок, я не предвижу, что у вас возникнут проблемы с использованием EF.