Где линия между DAL и ORM?

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

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

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

Ответ 1

ORM = Объектно-реляционное сопоставление

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

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

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

ORM - это вид DAL, но не все DAL являются ORM.

Ответ 2

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

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

Ответ 3

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

[Расширенное]

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

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

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

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

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

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

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

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

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

Ответ 4

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

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