2009-02-24 5 views
33

이 용어는 종종 서로 교환 할 수있게 던져지며 명확하게 중복되는 부분이 있지만 사람들이 DAL이라는 의미로 암시되지 않는 ORM이라는 말로 강하게 암시되는 것을 암시하는 것처럼 보입니다. 그게 뭐야? 이러한 유형의 시스템을 차별화하는 핵심 요소는 무엇입니까?DAL과 ORM 사이의 줄은 어디입니까?

예를 들어 데이터베이스, 테이블, 열 및 행 클래스를 구현하고 기존 데이터베이스의 자동 분석으로 채우고 간소화 된 상호 작용 등을 허용하는 코드가 있다고 가정 해 보겠습니다. 그것은 외부 키와 같은 데이터베이스 엔티티 사이의 구조적 관계를 이해, 실행 및 활용합니다. 모든 엔티티 모델을 서브 클래스 화하여 테이블 특정 기능을로드 할 수 있습니다.

DAL은 어느 정도까지입니까? ORM은 어느 정도입니까? 왜?

+0

@chaos - 왜 특수 용어 태그입니까 ?? DAL 및 ORM은 완벽하게 훌륭한 기술 약어입니다. –

+0

@DJ : 용어에 * 잘못된 *이 있음을 암시하기 위해 '전문 용어'를 사용하지 않습니다. Rich B의 괴상한 태그 다시 데타에 대한 또 다른 구경꾼에 의해 제안 된 것처럼, 나는 http://en.wikipedia.org/wiki/Jargon에 의해 안내 받기 위해 노력하고있다. – chaos

+0

컴퓨터 용어는 외부인에 의해 전문 용어라고 부를 수 있습니다. 그러나 여기에있는 모든 소프트웨어 전문가는 - 이것은 우리에게 전문 용어가 아닙니다. 그렇지 않으면 거의 모든 게시물은 특수 용어 –

답변

49

ORM은 = 객체 관계형 ORM에 매핑

, 응용 프로그램의 클래스/객체는 때때로 자동적으로, 지속성을위한 데이터베이스 테이블 및 운영에 매핑됩니다.

DAL은 = A DAL에서 데이터 액세스 레이어

는 데이터베이스 작업은 코드 외관 뒤에 숨겨져 있습니다.

ORM은 일종의 DAL이지만 일부 DAL은 ORM이 아닙니다.

+0

좋은 ORM은 DALness를 보이지 않지만 모두 보이게합니다. – yfeldblum

+10

이 내용이 이미 무엇을 말하고 있는지 알지 못하는 사람에게이 내용이 무엇인지 설명하지 못했습니다. DAL 사용자는 데이터베이스 테이블과 작업을 클래스와 개체에 매핑한다고 주장 할 수 있습니다. ORM은 외관 뒤에 숨어있는 물건으로 볼 수 있습니다. – dkretz

+3

@ [le dorfier] : 개체와 클래스를 테이블에 매핑 할 필요가 없습니다. DAL.RunSql ("Select * from MyTable", rowCollection)은 DAL이지만 ORM이 아닙니다 (엄밀히 말하면). –

7

나는 ORM이 모든 객체 집합을 관계형 데이터베이스에 매핑 할 수 있다고 생각합니다. DAL은 응용 프로그램에 따라 다르며 자연스럽게 다른 개체를 지원할 수는 없습니다.

ORM은 특별히 클래스를 데이터베이스 엔티티와주고받는 반면 DAL은 매핑없이 데이터베이스의 데이터에 액세스 할 수있는 방법 일 수 있습니다.

3

프로그래밍을 시작할 때 ORM이 존재하지 않았습니다. 첫 번째 ORM이 나왔을 때 DAL을 만드는 데 사용 된 외부 도구였습니다. 이제 DAL과 ORM이 혼합되었습니다. 그래서 많은 개발자들이이 용어를 서로 바꾸어 사용합니다.

DAL로 기능하는 ORM의 가장 잘 알려진 예는 NHibernate입니다. 다른 예로 Subsonic 및 CSLA.NET이 있습니다. 이것들은 모두 .NET 도구입니다. IIRC, ORM 도구는 Java 세계에서 시작되었습니다. 다른 기술 스택은 Java가 수행 한 작업을 복사합니다.

5

개체를 저장하지 않는 저장소 시스템에 연결하는 개체 지향 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을 작성한다는 사실을 변경하지는 않습니다.

+0

임피던스 불일치 처리를 확장 할 수 있습니까? – chaos