Продолжить библиотеку Microsoft Enterprise?

Корпоративная библиотека не так уж плоха, но блок данных не так уж хорош. Так что сохраните большую часть того, что вы получаете в корпоративной библиотеке. Также обратите внимание: большая часть корпоративной библиотеки сейчас переписывается, включая блок доступа к данным.
http://www.pnpguidance.net/Post/EnterpriseLibrary50UnityConfiguration.aspx

Но для доступа к данным вам следует посмотреть на Entity. Framework, Linq To SQL (он не мертв) или NHibernate (проверьте SummerOfNHibernate.com).

Помимо EntLib, вы также можете взглянуть на Prism.

Я ничего не имею против EntLib. Фактически, я сам использую его в основном для регистрации и обработки исключений в паре проектов.

Однако, как вы заметили, доступ к данным в библиотеке дает очень мало. Даже если стоимость его использования в ваших проектах невелика (поскольку у вас уже есть некоторый опыт работы с ним), все же существуют лучшие "продукты" доступа к данным (Linq2Sql, EF, SubSonic, NHibernate, LLBLGen ...), которые в длительный пробег сэкономит вам много времени.

Итог: если он не дает вам каких-либо серьезных преимуществ, не включайте его в проект только потому, что вы к нему привыкли. Проведите выходные за одной из новых технологий / продуктов, и я уверен, что это принесет большую пользу, чем использование DAAB.

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

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

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

EL PRO

• Microsoft в пространстве имен. Неудивительно, что для многих крупных организаций это соображение №1. Кстати, многие удивляются, когда читают лицензионное соглашение и понимают фактический уровень поддержки Microsoft EL.
• Проверено на многих крупных предприятиях по всему миру. Это не означает, что это лучшее решение, просто оно стабильно и оказывает незначительное влияние на производительность во время выполнения.
• [Доступ к данным], вероятно, лучшее решение, если вы хотите придерживаться старой школы, вручную созданной или сгенерированной SQL / хранимых процедур.

EL CON

• Медленный вывод на рынок или отсутствие поддержки для многообещающих такие практики, как ORM, DI / IoC или AOP
• Тяжелые с более высокими соответствующими накладными расходами, чем другие инфраструктуры, такие как Log4Net, в домене регистрации.
• Трудно настроить, если вы выйдете за пределы модели поставщика. Работа с изменениями исходного кода, подписью и проблемами развертывания / управления версиями GAC может быть гораздо более серьезной проблемой со сложной сетью библиотек DLL EL, чем с более легкой структурой.
• Некоторые из вещей, которые являются критическими для крупных предприятий такие потребности, как пакетная структура, не добрались до EL и все еще являются частным кодом в Avanade ACA framework.

Лично я думаю, что Enterprise Library страдает раздутием программного обеспечения . Я бы не стал считать его основополагающим «просто потому». У меня должна быть очень веская причина, чтобы использовать его в проекте. Я использовал некоторые из ранее выпущенных Application Blocks - когда они предлагались как таковые - но я скептически относился к переходу на полную Enterprise Library сейчас только потому, что мы использовали одну часть из многих. Там'

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

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

Я думаю, что Enterprise Library - хороший выбор. Это хорошо задокументировано и часто используется. Это бонус, особенно когда вы передаете код другим разработчикам. Я не думаю, что вы добавляете много накладных расходов или сложности, поскольку все это довольно хорошо упаковано и установлено в GAC.

Вот очень содержательная статья о Linq-to-SQL: Уровень доступа к данным ( DAL) Shrinker .

Впервые я начал использовать Microsoft Data Access Application Block несколько лет назад. Как только Linq был представлен, я заставил себя изучить его. С тех пор я включил его во все свои проекты.

Почему бы не расширить и не оценить SubSonic на меньшем проекте? Роб Коннери сейчас работает на MS и проделал хорошую работу, создав «швейцарский армейский нож» ORMS. Этот проект, безусловно, хорошо известен, так что вам, возможно, удастся представить его клиентам и коллегам.

В SubSonic входит:

• Свободный интерфейс
• Поддержка MS SQL, Oracle, MySql

• Aggregate запросы:

  const double expected = 55.5922;

   // перегрузка # 1
  двойной результат = новый
   Выберите (Aggregate.Avg ("UnitPrice"))
   .Из (Product.Schema)
   .ExecuteScalar <двойной> ();
  Assert.AreEqual (ожидается, результат);
  

  Время разгона составляет около получаса. Если вы в конечном итоге возненавидите это, вы даже не потратили ни дня!