Entity Framework - подходит ли он для приложений уровня предприятия?

Question

У меня есть веб-приложение с:

• 1 терабайт DB
• 200 + столы
• Не менее 50 таблиц с 1+ миллионами записей в каждой
• 10 + разработчики
• 1000 одновременных пользователей

В этом проекте в настоящее время используется Ad-Hoc Sql, созданный с помощью специального решения ORM. Вместо поддержки пользовательского ORM (в котором отсутствуют многие дополнительные функции), я думаю переключиться на Entity Framework.

Я использовал EF 4.1 (Code-First) в меньшем проекте, и он работал довольно хорошо, но можно ли его масштабировать для гораздо более крупного проекта выше?

Answer 1

Я (очень) согласен с мыслями marvelTracker (и Ayende).

Вот некоторая дополнительная информация:

Ключевая стратегия

Существует общеизвестная стоимость использования GUID в качестве первичных ключей. Он был описан Джимми Нильссоном и был общедоступен на http://www.informit.com/articles/article.aspx?p=25862.. NHibernate поддерживает стратегию первичного ключа GUIDCOMB. Однако добиться этого в EntityFramework немного сложно и требует дополнительных шагов.

Перечисления

EntityFramework изначально не поддерживает перечисления. До июня CTP, который добавляет поддержку Enums http://blogs.msdn.com/b/adonet/archive/2011/06/30/walkthrough-enums-june-ctp.aspx, единственный способ отобразить перечисления - использовать обходные пути. Пожалуйста, посмотрите: Как работать с Enums в Entity Framework?

Запросы:

NHibernate предлагает множество способов запроса данных:

• LINQ (с использованием re-linq-провайдера re-motion, https://www.re -motion.org / web / )
• Именованные запросы, инкапсулированные в объектах запросов
• ICriteria / QueryOver для запросов, критерии которых заранее не известны
• Использование проекций и агрегатов QueryOver (в некоторых случаях нам нужны только конкретные свойства объекта. В других случаях нам могут понадобиться результаты статистической функции, например, усреднение или счет):
• PagedQueries: чтобы избежать чрезмерной нагрузки на пользователя и повысить отзывчивость приложений, большие наборы результатов обычно разбиваются на меньшие страницы результатов.
• MultiQueries, которые объединяют несколько запросов ICriteria и QueryOver в одну и ту же базу данных
• Отдельные запросы, которые являются объектами запросов в частях приложения без доступа к сеансу NHibernate. Эти объекты затем выполняются в другом месте с помощью сеанса. Это хорошо, потому что мы можем избежать сложных репозиториев многими методами.

ISession's QueryOver:

// Query that depends on a session:
premises = session.QueryOver<Premise>().List();

Отдельный запрос:

// Full reusable query!
var query = QueryOver.Of<Premise>();

// Then later, in some other part of ther application:
premises = query.GetExecutableQueryOver(session).List(); // Could pass IStateleSession too.

Открытый исходный код

NHibernate имеет множество проектов, доступных на http://sourceforge.net/projects/nhcontrib/

Этот проект предоставляет ряд очень полезных расширений для NHibernate (среди прочих):

• Поставщики кэша (для кэша 2-го уровня)
• Внедрение зависимостей для сущностей без конструктора по умолчанию
• Полнотекстовый поиск (интеграция Lucene.NET)
• Пространственная поддержка (интеграция NetTopologySuite)

Поддержка

EntityFramework поставляется с поддержкой Microsoft. NHibernate имеет активное сообщество:

• https://stackoverflow.com/questions/tagged/nhibernate
• http://forum.hibernate.org/
• http://groups.google.com/group/fluent-nhibernate

Также взгляните на: http://www.infoq.com/news/2010/01/Comparing-NHibernate-EF-4

Answer 2

NHibernate - лучший выбор для вас, потому что он имеет хорошую поддержку сложных запросов, кэширование второго уровня и отличную поддержку оптимизаций.Я думаю, что EF добирается туда.Если вы имеете дело с устаревшими системами, лучше всего подходит NHibernate.

http://ayende.com/blog/4351/nhibernate-vs-entity-framework-4-0

Answer 3

Подходит это интересный термин.Это можно использовать?Да, и вы найдете ряд полезных функций, которые хорошо подходят для быстрой разработки приложений.Тем не менее, это в некоторой степени наполовину запеченная технология, и в ней отсутствуют многие расширенные функции ее собственного предшественника, LINQ to SQL (даже через 3 года после ее первого выпуска).Вот несколько неприятностей:

• Плохая поддержка сложных LINQ
• Нет типов свойств Enum
• Отсутствуют преобразования SQL (анализ даты, времени, анализ int и т. Д.) (ХотяВы можете реализовать их с помощью функций, определенных моделью)
• Плохая читаемость SQL
• Проблемы с сохранением нескольких ресурсов ssdl / csdl / msl независимыми для шардинга (на самом деле это не проблема Code Code)
• Проблемы с запуском нескольких параллельных транзакций в различных объектных контекстах
• Проблемы со сценариями обособленных сущностей

Тем не менее, Microsoft приложила немало усилий и, надеюсь, продолжит совершенствоватьчерез некоторое время.Лично я потратил бы время на реализацию хорошо абстрагированного шаблона Repository / Unit of Work, чтобы ваш код вообще не знал, что он использует EF, и при необходимости вы можете переключиться на другого поставщика LINQ to DB в будущем.

Большинствосовременные ORM станут шагом вперед от специального SQL.