Где проходит граница между DAL и ORM?

Question

Термины часто встречаются взаимозаменяемо, и, очевидно, они значительно перекрываются, но так же часто кажется, что люди видят что-то сильно выраженное, говоря, что система - это ORM, которая не подразумевается как DAL. Что это такое? Каковы, если таковые имеются, ключевые моменты, которые отличают эти типы систем?

Например, допустим, у меня есть некоторый код, который реализует классы Database, Table, Column и Row, заполняя их автоматическим анализом существующей базы данных, позволяя упростить взаимодействие и так далее. Он понимает, применяет и использует структурные связи между объектами базы данных, такие как внешние ключи. Все модели сущностей могут быть разделены на подклассы для загрузки на них функциональности, специфичной для таблицы.

Насколько это DAL? В какой степени это ORM? Почему?

Answer 1

ORM = объектно-реляционное отображение

В ORM классы / объекты в приложении отображаются в таблицы базы данных и операции для сохранения, иногда автоматически.

DAL = Уровень доступа к данным

В DAL операции с базами данных скрыты за фасадом кода.

ORM является разновидностью DAL, но не все DAL являются ORM.

Answer 2

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

Мало того, но ORM специально занимается отображением классов в / из объектов базы данных, в то время как DAL может быть просто способом доступа к данным в базе данных, без какого-либо отображения .

Answer 3

Любой объектно-ориентированный DAL, подключающийся к любой системе хранения, которая не сохраняет объекты, реализует ORM. Обычно считается, что ORM означает что-то похожее на Hibernate, но важная вещь - это обработка несовпадений импеданса.

[Expanded]

На уровне данных возникает несоответствие импеданса, когда вы отображаете данные одного типа (реляционные) в данные другого (OO).

Например, сколько раз вы видели строку, подобную приведенной ниже, в вашем DAL?

db.AddInParameter(dbCommand, "Name", DbType.String, name);

Или с другой стороны

customerId = Convert.ToInt64(dr["CustomerID"].ToString());

При отображении примитивных типов данных возникает много проблем.

На уровне объекта ваш DAL должен возвращать структуры, которые вы намереваетесь использовать. Будь то какой-то бизнес-объект или просто набор необработанных данных. И ваш собственный DAL, и ORM должны справиться с этим.

На уровне проектирования объекты, которые вы строите, отражают ваши сохраненные данные. Таким образом, структурная разница может возникнуть. Они также обрабатываются для вас в решениях ORM, но вы должны будете сделать то же самое в DAL. Например, в вашем ОО-коде было бы неплохо реализовать правильное наследование, но это нелегко преобразовать в нечто реляционное.

Я просто хотел отметить, что ORM - это термин, придуманный для обозначения продуктов, которые автоматизируют многое из того, что вам уже придется делать в рамках вашего DAL. Решения ORM облегчат жизнь и обеспечат большое количество преимуществ качества / производительности. Но это не меняет того факта, что одним из основных компонентов вашего DAL является создание собственного ORM.

Answer 4

ORM не существовало, когда я начал программировать. Когда появились первые ORM, они были внешними инструментами, использованными для создания DAL. Теперь дни, DAL и ORM смешались. Вот почему многие разработчики используют термины взаимозаменяемо.

Самым известным примером ORM, который функционирует как DAL, является NHibernate. Другими примерами являются Subsonic и CSLA.NET. Это все инструменты .NET. Инструменты IIRC, ORM появились в мире Java. Затем другие технологии копируют то, что сделала Java.