Какой ORM вы бы выбрали для работы с устаревшими базами данных?

Question

Я нахожусь в процессе интеграции ряда устаревших систем. Каждый из них имеет разные базы данных; и мне нужно будет написать код доступа к данным для большинства из них.

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

Какую ORM вы бы выбрали для этой задачи? Я хотел бы использовать тот же ORM для всего проекта; и мои требования:

• Возможность переименования таблиц или столбцов в коде; но сохраните старое имя в базе данных.
• Разумная генерация кода
• Эффективная поддержка LINQ (запросы LINQ к модели данных должны быть переведены в эффективный SQL).
• Сгенерированные классы данных предпочтительно должны быть POCO's .
• Предпочтительно поддержка различных механизмов баз данных.

В настоящее время у меня больше всего опыта работы с LINQ-To-SQL; но я чувствую, что это может быть неправильный выбор для этого проекта. Я готов потратить некоторое время на изучение новой основы.

Answer 1

По-моему, ORM может доставить вам больше хлопот, чем сэкономить. Если у вас есть несколько разных унаследованных баз данных, некоторые из которых плохо спроектированы, вам может быть проще создать уровень доступа к данным на более низком уровне, чем ORM. Шаблоны корпоративной прикладной архитектуры Фаулера неплохо справляются с каталогизацией различных подходов к структурированию слоев доступа к данным.

Некоторые уровни доступа к данным могут быть доступны для решения для генерации кода; однако наличие разнообразных схем (некоторые, как вы говорите, неаккуратно) предполагает, что подход «один размер подходит всем» может не сработать или может потребовать непропорциональных усилий, чтобы он хорошо работал со всеми устаревшими базами данных.

Answer 2

nHibernate будет вашим лучшим выбором, он предлагает поддержку POCO, включает поддержку для каждой базы данных, которую я знаю, и поддержка LINQ более чем достаточна. Похоже, вы захотите сгенерировать свои файлы сопоставления, есть шаблоны для mygeneration и codemith, которые помогут вам сделать это и избежать тонны ручной работы. (после первоначального поколения легко настраивать и изменять имена таблиц, отношения и т. д., что намного сложнее в большинстве основанных на поколении сред)

Answer 3

Я предполагаю, что вы работаете с C #?

Я бы сказал, может быть, попробовать SubSonic, это был хороший выбор, когда база данных уже есть, особенно когда дело касается процедур и представлений магазина. Там нет xml для настройки, как nHib, и вы можете начать работать с ним через несколько часов (или 20 минут, если вы знаете, что делаете). Также есть поддержка нескольких баз данных.

Часть Linq, я думаю, что Роб и Ко сейчас добавляются, так что это тоже может быть там, но это будет частью последних вещей, которые я еще не пробовал.

http://subsonicproject.com/

Answer 4

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

Answer 5

nHibernate соответствует большинству ваших требований. Единственное ограничение - linq; однако, у них есть постоянный разработчик, пожертвованный спонсором, который работает над добавлением поддержки запросов linq.

Он поддерживает множество механизмов баз данных, он бесплатный, он может использовать POCO. У этого есть много крючков, чтобы сделать различные части расширяемыми.

Answer 6

LINQ to SQL работает только с SQL Server. ADO.NET Entity Framework работает с любой базой данных, поддерживаемой ADO.NET.

Единственное, что я вижу в вашем списке, который не реализован, это то, что классы не являются POCO. В частности, плохая идея выставлять одну из них в веб-сервисе, поскольку данные, относящиеся к реализации, также будут сериализованы.