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

Question

Я только начинаю проект, и, поскольку этот проект личный, мне интересно, каковы преимущества использования корпоративной библиотеки?Мы используем версию 2 для нескольких проектов в офисе, но я не совсем уверен (не считая передовой практики) в ее преимуществах, особенно в компоненте базы данных.Любой совет?Спасибо

Answer 1

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

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

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

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

Answer 2

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

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

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

Answer 3

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

Answer 4

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

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