Для тех, кто знает внутреннюю работу NHibernate, как вы думаете крупномасштабное веб-приложение, как говорят facebook / MySpace будет использовать NHibernate?
Или NHibernate хорошо подходят для более низкого трафика сайтов, таких как сайты компаний и т.д.? т.е. не предприятие готова из-за его болтливые природы?
NHibernate не болтливый вообще. О масштабируемости, там уже был вопрос о группах отеля NH , что было больше о сложности базы данных , то трафик, но все еще может быть интересно для вас.
Даже если всегда есть жалобы о ненужных-х запросов на каждом ОРМ, из-за общего характера ОРМ, это не значит, что это болтливый. С другой стороны, она оптимизирует ситуации, в которых это было бы слишком сложным для оптимизации в рукописной DAL-х. Например. партии запросов или отложенная загрузка.
NHibernate довольно легкий вес по сравнению с другими ORM-х и по сравнению с его мощными функциями.
NHibernate (как и любой другой ORM) можно было бы считать излишним, если нет объектно-ориентированной бизнес-модели, но вам необходимо оптимизировать для достижения максимальной производительности. Я не думаю, что Google может использовать NHibernate для своей поисковой системы, например.
Редактировать:
Производительность и мощность NHibernate не полностью бесплатно. Она требует, чтобы разработчики понимают, по крайней мере, с основами реляционных баз данных. попробуйте другой ORM, чтобы скрыть всю реляционные проблематику, что приводит к гораздо более неоптимизированном поведению.
NHibernate является профессиональная шутка. В моей компании, ее использование было запрещено по нескольким причинам. Как инструмент довольно непродуктивный; вы будете тратить много времени, пытаясь выяснить, или найти альтернативные стратегии в дефицитный документации.
Намного лучше, использовать свой собственный сгенерированный DAL и SP, чтобы достичь высокой производительности. Вы будете иметь кэшированный план выполнения, и в конце концов, что это то, что действительно имеет значение.
NHibernate не имеет расширенную поддержку для Memcached, который специально, что вы собираетесь использовать, если вы хотите построить масштабируемое веб-решение, как Facebook.
Я работаю в игровой компании социальной, и мы специально запрещено использовать NHibernate, в частности.
NHibernate поддерживает кэширование запросов, кэширование 2-го уровня на основе первичных ключей, а также кэш сеанса для повторных заходов на тот же объект в одной и той же сессии.
Это все большая помощь, но до тех пор, как вы ударяете базу данных с большой нагрузкой, вы будете иметь проблемы масштабирования. Лучший способ масштабирования базы данных, чтобы свести к минимуму количество времени, которое вы на самом деле должны использовать его. Распределенный кэш, такие как кэш, и кэширование ваших выходных (либо после datacrunched представления или HTML) являются лучшими способами масштабировать приложения. Если клиенты регулярно обращаться к базе данных, вы делаете это неправильно, ORM или нет. В приложении .NET, как типичное приложение MVC, имеет преимущество быть в состоянии использовать varyby кэширование вывода, пончик и кэширование пончика отверстия, а также клиент для кэша памяти для использования с NHibernate и для ViewModels.
