NHibernate vs Entity Framework 4.

  Недавно пришлось делать сравнение NHiberante и EF4. Стоит отметить, что мой личный опыт включает в себя только использование NHibernate, и остальные изыскание проводились исключительно с позиции стоит ли EF4 усилий по своему изучению. Вкратце преимущество каждого перечислены ниже.


Преимущества NHibernate

1. Пакетное чтение (MulityQuery, Future)
2. Пакетная запись, настраиваемая в конфиге. 
3. Пакетная ленивая загрузка коллекций, сокращающая проблему N +1 
4. Сверхленивая загрузка коллекций (Order.OrderLines.Count приводит к select count(*) )
5. Возможность постраничной выборки и фильтрации коллекций. 
6. Разнообразные способы выборки: HQL, ICriteria, QueryOver, LINQ, SQL(включая хранимые процедуры) и трансформации результатов с использованием IResultTransformer.
7. Кеш второго уровня. 
8. Большое количество точек расширения, открывающих широкие возможности по модификации поведения 
9. Как следствие из предыдущего пункта, существует большое большое количество расширяющих фреймворков. Примеры:
   • NHibernate.Envers - аудит 
   • NHibernate.Validator - думаю понятно :)
   • NHiberante.Search - Полнотекстовый поиск с использованием Lucene.Net
   • NHibernate.Shards - горизонтальное масштабирование приложений. 
   • Rhino.Security - библиотека для разграничения прав доступа. 
10. Разнообразные способы маппинга объектов на бд:
    • xml
    • аттрибуты
    • маппинг кодом (2 отдельных фреймворка + встроенная поддержка)
      • по классам
      • по соглашениям.
11. Более мощный язык объектных запросов (HQL vs Entity SQL), позволяющий выполнять объектные DML-команды без загрузки объектов в память. 
12. Встроенная поддержка для логгирования генерируемых sql-команд. 
13. Более 10 разнообразных id-генераторов, включая наиболее эффективные для ORM HiLo и guid.comb.
14. Возможность маппинга разнообразных пользовательских типов (шифрованные строки, локализованные свойства, запись Enum как строки, и многое другое)
15. Поддержка readonly свойств. 
16. Поддеркжа коллекций элементов (например IList<int>)
17. Поддержка маппинга словарей (Dictionary).
18. Сильное сообщество программистов. 

Преимущества EF

1. Лучшая поддержка LINQ.
2. Свойства объектов не обязательно должны быть виртуальными.  
3. Microsoft.
4. Наличие визуального редактора от Microsoft.

Мой выбор очевиден, NHibernate. Остальное решать вам. 

Оседлать AssemblyVersion.

   Наверно перед каждым разработчиком встаёт задача управлением версиями сборок. На заре своей карьеры я делал это самым простым способом - переписывал руками. Потом этот процесс был автоматизирован с nant'ом: он сканировал AssemblyInfo.cs по всему решению, и переписывал версию. Потом через подключение через ссылку общего для всех проектов файла SolutionVersion.cs.
  Но в этом решении по прежнему оставался один минус: версия сборки имеет значение только в момент компиляции проекта, и ее нахождение в системе контроля версий бессмысленно. Но если не класть SolutionVersion.cs в контроль версий, то в новой рабочей копии сначала придётся запустить сборку приложения, чтобы его сгенерировать. Иначе студия будет сообщать нам об ошибке. К счастью, решение есть. И оно не такое уж сложное. Давайте по шагам.

1. Создаём в корневой папке решения пустой файл SolutionVersion.cs
2. Подключаем его во все проекты как ссылку.



3. Добавляем его в список файлов, которые не будут отслеживаться системой контроля версий (файлы .gitignore; .hgignore).
4. Откройте любым редактором файл проекта .csproj, и ищите в самом конце такие строки:
   

    
     <!-- To modify your build process, add your task inside one of the targets below and uncomment it. 
          Other similar extension points exist, see Microsoft.Common.targets.
     <Target Name="BeforeBuild">
     </Target>
     <Target Name="AfterBuild">
     </Target>
     -->
   

   Если есть - удаляем комментарии, и пишем свою задачу. Если их нет, то просто допишите pre-build задачу перед закрывающим тегом </Project>
   

    
     <Target Name="BeforeBuild">
       <Exec Command="echo //DO NOT EDIT &gt; $(SolutionDir)\SolutionVersion.cs"  condition="!Exists('$(SolutionDir)\SolutionVersion.cs')">
       </Exec>
     </Target>
   

5. И настроим в своём любимом build-tool генерацию этого же файла.

  Собственно, идеальный результат достигнут: версия сборки не хранится в контроле версий, и нам не надо предварительно запускать build, чтобы visual studio не выдавала ошибок.