Какова значительная разница между активной записью и картопостроителем данных базирующийся ORMs?

Я должен признать, что не знаю доктрины или Ксистера , но я могу хотя бы кое-что сказать понимание разницы между Active Records, реализованными в Ruby, и ORM, такими как SubSonic, Linq to SQL, nHibernate и Telerik. Надеюсь, это по крайней мере даст вам что-то для дальнейшего изучения.

Active Record Ruby - это его родная библиотека доступа к данным - это не отображение существующей библиотеки интерфейса SQL (например, .NET SqlDataTables) в конструкции языка - это ] интерфейсная библиотека. Это дало разработчикам больше возможностей для создания библиотеки более интегрированным образом, но также потребовалось, чтобы они реализовали широкий спектр инструментов SQL, которые вы обычно не найдете в ORM (например, команды DDL являются частью интерфейса Active Record Ruby. ).

ORM сопоставляются с базовой структурой с помощью ручного шага, на котором генератор кода открывает базу данных и просматривает ее, создавая объекты, соответствующие таблицам (и хранимым процедурам), которые он находит. Эти объекты создаются с использованием низкоуровневых программных конструкций SQL, предлагаемых как часть языка (например, .NET System.Data.Библиотеки Sql и SqlClient). Цель здесь состоит в том, чтобы предоставить ориентированным на записи реляционным базам данных более плавный и понятный интерфейс во время программирования: уменьшить «несоответствие несоответствия» между реляционной моделью и объектно-ориентированным программированием.

В качестве примечания: MS предприняла очень «похожий на Active Record» шаг при встраивании конструкций на родном языке в C # через Linq to SQL и Linq to Entities.

Надеюсь, это поможет!

Разница в том, насколько объекты вашего домена отделены от уровня доступа к данным. В ActiveRecord все это один объект, что делает его очень простым. Особенно, если ваши классы сопоставлены один в один с вашей базой данных. Data Mapper более гибкий и позволяет легко тестировать ваш домен независимо от кода инфраструктуры доступа к данным. Но сложность имеет свою цену.

Основное отличие состоит в том, что в DataMapper модель определяется в самом классе ruby:

class Post
  include DataMapper::Resource

  property :id,         Serial
  property :title,      String
  property :body,       Text
  property :created_at, DateTime
end

В то время как в ActiveRecord класс в основном является пустым, а framwork сканирует базу данных. Это означает, что вам нужна либо предопределенная база данных, либо использование чего-то вроде миграции для создания схемы, при этом модель данных будет отделена от ORM.

DataMapper.auto_migrate!

сгенерирует для вас схему.

ActiveRecord отличается в этом отношении:

class Post < ActiveRecord::Base
end

В DataMapper нет необходимости в миграциях, поскольку автоматические миграции могут генерировать схему или искать различия между моделью и базой данных и выполнять миграцию за вас. Также имеется поддержка ручной миграции, которую можно использовать в нетривиальных случаях.

Кроме того, DataMapper является гораздо более «рубиновым» синтаксисом, и такие функции, как отложенная загрузка при выполнении условий с цепочкой (например, ActiveRecord в Rails 3), присутствуют с самого начала.

Datamapper также имеет функцию, заключающуюся в том, что каждая запись в базе данных сопоставляется с одним рубиновым объектом, что неверно для ActiveRecord. Итак, если вы знаете, что записи в базе данных одинаковы, вы знаете, что две ссылки на объект ruby ​​также будут указывать на один и тот же объект.

С другой стороны, хотя Rails 3 может обещать вам заменяемые фреймворки, Datamapper railtie (dm-rails) не готов к производству, и многие функции могут не работать.

См. Эту страницу для получения дополнительной информации.