Пожалуйста, рекомендуйте .NET ORM для разработки N-уровня

Ответ 1

Я бы порекомендовал Entity Framework v4. Он значительно улучшился после версии v1 и поддерживает все, что вам нужно, за исключением открытого источника:

• EF поддерживает очень широкий спектр отображений, включая TPH, TPT и TPC. Поддерживает POCO отображение, позволяющее сохранить логику персистентности отдельно от вашего домена.
• EF имеет обширную и превосходную поддержку LINQ, предоставляя простой в использовании, проверенный временем запрос вашей модели. Компоненты EF Futures, такие как Code-Only, упрощают работу с EF еще больше, обеспечивая чистый код, проверенный временем, свободный API для определения вашей модели, Выбирая условную конфигурацию, Code-Only может радикально сократить время разработки модели, позволяя вам перейти к бизнесу без всяких хлопот с визуальной моделью и несколькими файлами сопоставления XML.
• Это бесплатно как часть .NET 4. (Извините, предпочтение от Open Source не может быть выполнено здесь.)
• EF обеспечивает отличное решение OOB для N-уровня с помощью объектов самоконтроля
  • Информация для самостоятельного отслеживания использует открытый XML-формат для передачи данных отслеживания, поэтому поддержка отслеживания может быть добавлена ​​на платформы не .NET.
• Производительность EF v4 очень хорошая, так как обширная работа была выполнена на генераторе запросов
  • Смотрите Запись в блоге ADO.NET по теме
• EF предоставляет чрезвычайно богатые инструменты визуального проектирования и позволяет осуществлять широкую настройку генерации кода с помощью пользовательских T4 шаблонов и рабочих процессов
• В EF v4 были введены многочисленные интерфейсы, в том числе IObjectSet <T> и IDbSet <T> , которые значительно улучшают тестируемость вашего пользовательского контекста.
• EF v4 является неотъемлемой частью .NET 4 и является центральным компонентом всех текущих и будущих инициатив Microsoft в отношении данных. В составе .NET ее документация довольно обширна: MSDN, Блог EFDesign, Блог ADO.NET, десятки сайтов и блогов .NET и программирования предоставляют огромное количество документации и поддержки для платформы.

Ответ 2

Работая со следующим:

• NHibernate

• LLBLGen

• Entity Framework

• LINQ to SQL

• DataObjects.Net

• OpenAccess

• DataTables

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

В основном, я обнаружил, что эти сильные стороны и wekanesses связаны с общим типом ORM, который относится к следующим двум категориям:

• Тяжелый вес

  • В эту категорию попадают LLBLGen, OpenAccess, Entity Framework (до 4.0), DataObjects. У ORM с большим весом обычно есть сущности и коллекции, которые наследуются от базового класса, специфичного для ORM (т.е. EntityBase). Эти ORM часто предлагают богатую поддержку времени разработки, генерации кода и глубинных функций времени выполнения (таких как отслеживание состояния, отслеживание транзакций, поддержание связи и т.д.).

  • The Pro: проще и быстрее разрабатывать встроенный API для взаимодействия с самими сущностями во время выполнения (т.е. от LLBLGen entity.Fields [ "MyField" ]. IsChanged или entity.IsNew или entity.Fields [ "MyField" ]. DbValue

  • Кон: Тяжесть и зависимости. С помощью этих ORM ваши бизнес-объекты теперь привязаны непосредственно к API ORM. Что делать, если вы хотите перейти на другую ORM? И что мешает младшим разработчикам злоупотреблять расширенными функциями API ORM, чтобы исправить простую проблему сложным решением (я видел эту тонну)? Использование памяти также является большой проблемой для этих ORM. Коллекция из 5000+ объектов может легко принимать 100 МБ ОЗУ с некоторыми из вышеперечисленных ORM. Сериализация - еще одна проблема. С тяжести объектов сериализация может быть очень медленной... и, вероятно, она не будет корректно десериализоваться по другую сторону провода (удаленные WCF или .NET и т.д.). Ассоциации могут оказаться неправильно связанными или определенные поля не могут быть сохранены. Некоторые из вышеперечисленных ORM построили механизмы сериализации для улучшения поддержки и скорости... но ни один из них, который я видел, не предлагает полной поддержки для разных форматов (т.е. Вы получаете двоичную, но не поддержку json или xml).

• Облегченный

  • LINQ to SQL, Entity Framework POCO, NHibernate (вроде) попадают в эту cateogry. Легкие ORM обычно используют POCOs, которые вы можете создать в файле в VS (конечно, вы также можете использовать шаблон T4 или генератор кода).

  • The Pro: Легкий. Это просто. ORM агностические бизнес-объекты.

  • Функции Con: Less, такие как обслуживание графа сущности, отслеживание состояния и т.д.

Независимо от того, какой ORM вы выберете, мои личные предпочтения - придерживаться LINQ и ORM независимого синтаксиса поиска (а не собственный API ORM для извлечения, если он есть).

Что касается конкретных упоминаний, вот мои краткие мысли: - NHibernate: Позади время мудрое. Многое сохранение файлов сопоставления xml (хотя Fluent NHibernate действительно облегчает это).

• LLBLGen: Самый зрелый ORM, с которым я работал. Легко запустить новый проект и начать работу. Лучший дизайнер. ОЧЕНЬ тяжелый вес. Богатый ОЧЕНЬ мощный API. Лучшая скорость, с которой я столкнулся. Поскольку это не новый парень на блоке, некоторые из новых функций, использующих более новую технологию, не реализованы, как и должны быть (LINQ специально).

• Entity Framework: класс POCO в 4.0 выглядит многообещающим. 3.5 не имеет этого, и я бы даже не подумал об этом. Даже в 4.0, не имеет большой поддержки LINQ и создает плохой SQL (может делать сотни запросов БД для одного запроса LINQ). Поддержка дизайнеров оставляет желать лучшего, когда речь заходит о крупных проектах.

• LINQ to SQL: отличная поддержка LINQ (лучше, чем любая другая, кроме DataObjects.Net). Поддержка промежуточного сохранения (сохранение/обновление). Очень легкий (POCO). Поддержка дизайнера плохо работает (нет обновления от БД). Низкая производительность при расширенных запросах LINQ (может делать сотни запросов БД)

• DataObjects.Net: действительно отличная поддержка и производительность LINQ. Предлагает самую близкую вещь, которую я видел POCO в тяжелой ORM. Действительно новая, мощная, перспективная технология. Очень гибкий.

• OpenAccess: не работал с ним тонна, но это немного напоминает LLBLGen, но не как функциональность, богатую или зрелую.

• Таблицы данных: Нет комментариев

Ответ 3

Почему бы не попробовать NHibernate?

Ответ 4

Еще один голос для EF здесь.

• Очень легко тестировать единицы. Вы можете написать свои собственные сущности домена и сделать их разумно свободными от понимания устойчивости, используя подход POCO. Затем вы можете обмануть интерфейс базы данных и протестировать логику приложения без реальной базы данных.

• Поддерживает LINQ, так что, если вы правильно напишете LINQ, он преобразует только один оператор SQL, отправляемый на сервер.

Ответ 5

Я использую продукт под названием LightSpeed, он работает очень хорошо и плавно интегрируется в Visual Studio 2010 и 2008. я использовали его с Sqlite, однако он поддерживает множество rdbms. Он также имеет очень приятную функцию, которая позволяет создавать объекты POCO, которые можно использовать с WCF, отличная экономия времени! Сначала я использовал бесплатный экспресс-выпуск, но вскоре обновился.

LightSpeed ​​- это лучшее высокопроизводительное .NET-моделирование домена и каркас отображения O/R. Поддержка LINQ первого класса, интеграция с дизайнерами Visual Studio 2008 и 2010 и наша известная высокопроизводительная базовая среда позволяют создавать более быстрые и легкие, чем когда-либо ранее, богатые доменные модели.

Ответ 6

Используя OpenAccess в нескольких проектах, я должен сказать, что он соответствует всем вышеперечисленным критериям. Одна система, над которой я работал, была основана на службах WCF, которые говорили с несколькими типами клиентов (смарт, веб, другие службы WCF и т.д.). Благодаря многоуровневой архитектуре службы WCF использовали OpenAccess как механизм сохранения. Я особенно люблю масштабирование, которое выполняет OpenAccess. Интеллектуальный кеш второго уровня (кэш L2) делает отличную работу там, и он может быть распространен. На самом деле я бы не назвал OA тяжелым весом... Вы даже не наследуете базовый класс. Также большой плюс есть инструменты для выполнения повседневных задач разработчика (создание новой схемы БД, схем слияния и т.д.), Интегрированных в визуальную студию.

Ответ 7

Об EF4... Не используйте его в большом проекте с большим количеством таблиц и множеством данных и множеством пользователей. Я сделал эту ошибку, и теперь я ищу замену.

1-Плохая генерация запросов, особенно в больших иерархиях TPT. Будьте готовы к 5000-строчному запросу для иерархии из 15 таблиц!

2-Чрезвычайно медленный дизайнер, когда число таблиц растет. 45 секунд, чтобы свернуть/развернуть объект в модели с 240 объектами.

3-Серьезная проблема с отношениями x-to-many. Предположим, что у вас есть объект Order и Customer. Каждый заказ имеет Клиента, и у каждого Клиента есть много ордеров. Существует свойство с именем Orders в классе Customer, которое будет заполнено, если вам вообще не нужны эти данные. Это означало, что в нашей системе коллекции до 1800 000 единиц были получены по какой-либо причине. Когда это происходит внутри транзакции с уровнем изоляции Snapshot..., который приводит к сбою всей системы. Фактического решения этой проблемы нет, у которой нет серьезных недостатков. Просто прочитайте документацию DataObjects.Net и посмотрите, как они справились с этой проблемой. Я обнаружил, что выплата 200 или 500 евро ничто по сравнению с тем, что вы получаете. Я даже могу получить версию с исходным кодом.

Если я не могу интегрировать свою систему с DO.Net, я буду искать другую, но это EF-вещь, она должна идти!