Рекомендация ORM для SQL Server

Question

Я собираюсь использовать SQL Server в своем проекте, для этого я хочу выбрать ORM с ним. У меня есть некоторый опыт использования NHibernate в качестве ORM . На самом деле, учитывая природу этого проекта (MySQL - бэкэнд), NHibernate действительно является выбором only .

Я также использовал строго типизированный набор данных в качестве ORM , и в качестве бэкэнда используется Microsoft Access. У меня также есть некоторый опыт работы с LINQ2SQL.

Теперь, я знаю, все пути ведут в Рим ; Многие ORM могут хорошо работать с сервером SQL. Но я хочу лучший ORM с точки зрения

1. Время разработки . То есть дизайнер перетаскивания, который отображает мои классы сущностей в схему базы данных. Так что, если я изменю свою схему, мои классы сущностей обновятся автоматически.
2. Поддержка нескольких баз данных . ORM должен иметь возможность обрабатывать запросы к нескольким базам данных оптимальным образом. Кроме того, поддержка нескольких строк подключения также должна быть выполнена легко.
3. Расширяемость . Если я хочу добавить запрос, я не хочу связываться с файлами дизайнеров; они - боль в шее, чтобы раздражать.

Это, наверное, так. Есть идеи?

Answer 1

Исходя из его требований, LLBLGen - это путь. Имейте в виду, что есть большие различия между LLBL и NH. LLBL это ORM / Generator, у ваших сущностей будет много предварительно сгенерированного кода, и он начинается с базы данных Так что, если вам нужно перетаскивать, то обязательно используйте LLBL.

Answer 2

LLBLGen может быть вариантом для вас.

Он имеет одно из лучших дизайнерских приложений и довольно многофункциональный.

Answer 3

Я хотел бы предложить DbBroker очень быструю и легкую библиотеку ORM.

Оптимизировано для SQL Server.

Сайт DbBroker

Answer 4

Строго типизированный набор данных не должен рассматриваться как инструмент OR / M. Набор данных (строго типизированный) - это просто представление данных в вашей базе данных в памяти (представление 1: 1).

Когда вы используете OR / M, вы «конвертируете» данные, которые существуют в вашей базе данных, в бизнес-объекты в памяти (которые не обязательно должны быть представлением вашей модели БД 1: 1, могут содержать дополнительную логику и т.д ...).

Может быть, вы могли бы взглянуть на MS Entity Framework, но, насколько я знаю сейчас, NHibernate все еще является лучшим решением, когда речь идет о функциях, производительности, абстракции, и вы имеете больший контроль над ним ( , тогда это может быть немного дороговато (во время разработки) (без перетаскивания, но вы можете сгенерировать свою модель данных из ваших отображений).

(поздний ответ - сбой сети ...)

Answer 5

• Типизированные наборы данных: 0/3
• Linq To Sql: 1/3. Он может выполнять пункт 3. Он может выполнять некоторые из пункта 2. Многократные строки подключения для разных запросов не проблема - но если вам нужно несколько баз данных в одном запросе, вам придется используйте представления или хранимую процедуру, чтобы добраться туда. Элемент 1 - перебор - если вы меняете схему, вы должны обновить сущности самостоятельно в конструкторе.

Answer 6

ADO .NET Entity Framework ?

Кажется, что в некоторой степени соответствует каждому из требований, хотя и не идеально