Какие ORM поддерживают какие стили рабочего процесса

Question

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

Рассмотрим эти штуковины :

• Сущность: простой старый объект. Оно делает вещи.
• Mapper: объект, который создает сущность из БД, или сохраняет ее назад.
• Таблица: таблица базы данных.
• Модель: Отдельная модель, которая описывает аннотация штучка .
• Проводка: A описание того, как части Таблица и сущность связаны между собой.

Это дает нам следующие стили рабочего процесса:

• Модель, управляемая: вы пишете модель, и создаются сущность, картограф и таблица.
• Управляемый сущностью: вы пишете класс, и генерируются Mapper и Table.
• Table Driven: вы создаете таблицу, и создаются сущность и картограф.
• Соединение: вы пишете Class, Table и Wiring, Mapper генерируется.

Вопросы:

• Есть другой стиль, который я не заметил?
• Какие ORM поддерживают какие стили?
• Есть ли для этого стандартный словарь? (Я только что выдумал.)

Answer 1

Из того, что я видел до сих пор, используя .NET, Entity Framework поддерживает все вышеперечисленное, а NHibernate поддерживает то, что вы называете Модельно-управляемым, Управляемо-управляемым и Проводным (без использования дополнительных сторонних библиотек).

NHibernate является портом Java Hibernate, поэтому я предполагаю, что они поддерживают одинаковые потоки.

Answer 2

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

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

Если вам нужно обойти существующую базу данных, тогдаблока, о создании базы данных из модели, вероятно, не может быть и речи.

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

Эти требования могут меняться на протяжении всей жизни проекта, так как вы можете начать с единственной цели.sumer и в будущем другие приложения могут напрямую обращаться к той же базе данных.Это может быть в том случае, если у вас есть рабочий процесс «Entity Based», как вы его называете, где у вас есть слой, который представляет фактические таблицы БД, а Модели, которые представляют ваши данные, используемые в вашей системе, абстрагируются от любых изменений в них.

И иногда требуется изменение, поэтому используемый вами ORM и рабочий процесс должны быть внимательны и, по крайней мере, частично способны выжить в будущем, которое может оказаться вне ваших рук.Представьте себе предпринимательскую (политическую) среду.Однажды к нам приходит администратор БД и говорит: «Теперь доступ ко всем данным осуществляется через SPROC».Подобные ситуации подталкивают вас к «картированию», как вы его назвали.

Answer 3

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

В библиотеке ActiveRecord в Ruby on Rails сам класс также выступает в качестве модели для таблицы с методами класса для find () и т. Д.Таким образом, вы, как правило, пишете только один класс для каждой таблицы.

Ruby AR отражает таблицу динамически (для имени таблицы, имен столбцов и типов), поэтому после создания схемы базы данных как-то достаточно:

class MyTable << ActiveRecord::Base; end

row = MyTable.find(7)
row.my_column1 = "foo"
row.save()

http://ar.rubyonrails.org/