NHibernate와 LINQ to SQL

StackOverflow https://stackoverflow.com/questions/26971

문제

실제 프로젝트에서 두 기술을 모두 사용해 본 적이 없는 사람으로서 이 두 기술이 어떻게 서로 보완되고 기능이 얼마나 겹치는지 아는 사람이 있는지 궁금합니다.

도움이 되었습니까?

해결책

LINQ to SQL은 클래스 별 테이블 패턴을 사용하도록합니다. 이 패턴 사용의 이점은 빠르고 쉽게 구현할 수 있으며 기존 데이터베이스 구조를 기반으로 도메인을 실행하는 데 거의 노력이 들지 않는다는 것입니다. 단순한 애플리케이션의 경우 이것은 완벽하게 수용 가능하며 (때로는 더 바람직 함), 더 복잡한 애플리케이션의 경우 개발자는 종종 도메인 중심 설계 패턴 (NHibernate가 촉진하는 것임).

클래스 별 테이블 패턴의 문제점은 데이터베이스 구조가 도메인 디자인에 직접적인 영향을 미친다는 것입니다. 예를 들어 고객의 기본 주소 정보를 포함하는 다음 열이있는 Customers 테이블이 있다고 가정 해 보겠습니다.

  • 거리 주소
  • 도시
  • 주
  • 우편

    이제 고객의 우편 주소에 대한 열도 추가하고 Customers 테이블에 다음 열을 추가한다고 가정 해 보겠습니다.

    • MailingStreetAddress
    • MailingCity
    • MailingState
    • MailingZip

      LINQ to SQL을 사용하면 도메인의 Customer 개체에 이러한 8 개 열 각각에 대한 속성이 있습니다. 그러나 도메인 기반 디자인 패턴을 따르고 있다면 Address 클래스를 만들고 Customer 클래스에 두 개의 Address 속성이 포함되어있을 것입니다. 하나는 우편 주소 용이고 다른 하나는 현재 주소 용입니다.

      간단한 예이지만 클래스 별 테이블 패턴이 어떻게 다소 냄새 나는 도메인으로 이어질 수 있는지 보여줍니다. 결국 그것은 당신에게 달려 있습니다. 다시 말하지만 기본 CRUD (만들기, 읽기, 업데이트, 삭제) 기능 만 필요한 간단한 앱의 경우 단순성 때문에 LINQ to SQL이 이상적입니다. 하지만 개인적으로 NHibernate를 사용하는 것을 좋아합니다. 왜냐하면 더 깨끗한 도메인을 가능하게하기 때문입니다.

      편집 : @lomaxx-예, 제가 사용한 예제는 단순했고 LINQ to SQL에서 잘 작동하도록 최적화되었을 수 있습니다. 나는 요점을 집으로 몰아 가기 위해 가능한 한 기본적으로 유지하고 싶었습니다. 데이터베이스 구조가 도메인 구조를 결정하는 것은 좋지 않거나 최소한 차선의 OO 디자인으로 이어질 수있는 몇 가지 시나리오가 있지만 요점은 남아 있습니다.

다른 팁

지금까지 놓친 두 가지 사항:

  • LINQ에서 SQL은 SQLServer를 제외하고 Oracle 또는 모든 데이터베이스에서 작동하지 않습니다. 그러나 제3자는 Oracle에 대해 더 나은 지원을 제공합니다. devArt의 dotConnect, DbLinq, Mindscape의 LightSpeed 그리고 알린크.(저는 이에 대해 개인적인 경험이 없습니다)

  • Linq에서 NHibernate로 LINQ를 사용하여 NHIBREATE를 사용할 수 있으므로 사용하지 않는 이유를 제거 할 수 있습니다.

또한 새로운 Nhibernate에 대한 유창한 인터페이스 Nhibernate의 매핑을 구성하는 것이 덜 고통스러운 것 같습니다.(Nhibernate의 문제점 중 하나를 제거)

업데이트

Nhiberate에 대한 Linq는 현재 Nhiberate v3에서 더 좋습니다. 알파.Nhiberate v3가 올해 말에 출시될 것으로 보입니다.

그만큼 엔터티 프레임 작업 .net 4부터 실제 옵션처럼 보이기 시작했습니다.

@케빈:당신이 제시하는 예의 문제는 당신이 잘못된 데이터베이스 디자인을 사용하고 있다는 것입니다.나는 고객 테이블과 주소 테이블을 생성하고 테이블을 정규화할 것이라고 생각했을 것입니다.그렇게 하면 제안하는 시나리오에 Linq To SQL을 확실히 사용할 수 있습니다.스콧 거스리는 Linq To SQL 사용에 관한 훌륭한 게시물 시리즈 확인해 보시길 강력히 권하고 싶습니다.

나는 Linq와 NHibernate가 함께 사용될 수 있다는 것을 의미하기 때문에 서로를 보완한다고 말할 수 없다고 생각하며 이것이 가능하지만 하나를 선택하고 고수하는 것이 훨씬 좋습니다.

NHibernate를 사용하면 매우 유연한 방식으로 데이터베이스 테이블을 도메인 개체에 매핑할 수 있습니다.또한 HBL을 사용하여 데이터베이스를 쿼리할 수도 있습니다.

Linq to SQL을 사용하면 도메인 개체를 데이터베이스에 매핑할 수도 있지만 Linq 쿼리 구문을 사용하여 데이터베이스를 쿼리합니다.

여기서 가장 큰 차이점은 Linq 쿼리 구문이 다음과 같다는 것입니다. 쿼리가 유효한지 확인하기 위해 컴파일러가 컴파일 타임에 확인합니다.

linq에 대해 알아야 할 몇 가지 사항은 .net 3.x에서만 사용할 수 있으며 VS2008에서만 지원된다는 것입니다.NHibernate는 VS2005뿐만 아니라 2.0 및 3.x에서도 사용할 수 있습니다.

NHibernate에 대해 알아야 할 몇 가지 사항은 도메인 개체를 생성하지도 않고 매핑 파일도 생성하지 않는다는 것입니다.이 작업은 수동으로 수행해야 합니다.Linq는 할 수 있습니다
자동으로 이 작업을 수행합니다.

Fluent NHibernate는 간단한 규칙에 따라 매핑 파일을 생성 할 수 있습니다.XML 작성이없고 강력한 형식입니다.

저는 최근에 성능상의 이유로 Linq에서 SQL 로의 전환을 NHibernate로 변경해야하는 프로젝트에서 작업했습니다.특히 L2S의 객체 구체화 방식은 NHibernate의 방식보다 느리게 보이며 변경 관리도 상당히 느립니다.또한 필요하지 않은 특정 시나리오에서는 변경 관리를 해제하기 어려울 수 있습니다.

예를 들어 WCF 시나리오에서 DataContext에서 분리 된 엔티티를 사용하려는 경우 변경 사항을 업데이트하기 위해 엔티티를 DataContext에 다시 연결하는 데 많은 문제가있을 수 있습니다.저는 NHibernate에 문제가 없었습니다.

L2S에서 놓칠 부분은 대부분 엔티티의 양쪽 끝에서 관계를 최신 상태로 유지하는 코드 생성입니다.하지만 NHibernate가이를 수행 할 수있는 몇 가지 도구가 있다고 생각합니다 ...

"LINQ"가 의미하는 바를 명확히 할 수 있습니까?

LINQ는 데이터 액세스 기술이 아니라 기본 구문으로 쿼리를 지원하는 언어 기능 일뿐입니다.특정 인터페이스 (예 : IQueryable)를 지원하는 모든 개체 모델을 쿼리 할 수 있습니다.

많은 사람들이 LINQ To SQL을 LINQ라고 부르지 만 전혀 정확하지 않습니다.Microsoft는 방금 .NET 3.5 SP1과 함께 LINQ To Entities를 출시했습니다.또한 NHibernate에는 LINQ 인터페이스가 있으므로 LINQ 및 NHibernate를 사용하여 데이터를 가져올 수 있습니다.

LINQ에서는 LINQ 자체에는 연결된 데이터베이스가 없기 때문에 LINQ to SQL을 의미한다고 가정합니다.SQL처럼 보이게 만드는 구문 설탕이 많은 쿼리 언어 일뿐입니다.

기본 예제에서 NHibernate와 LINQ to SQL은 모두 동일한 문제를 해결하는 것 같습니다.일단 통과하면 NHibernate가 진정으로 풍부한 도메인 모델을 만들 수있는 많은 기능을 지원한다는 것을 곧 알게됩니다.또한 LINQ to SQL을 사용하는 것과 거의 같은 방식으로 LINQ를 사용하여 NHibernate를 쿼리 할 수있는 LINQ to NHibernate 프로젝트가 있습니다.

먼저 두 가지를 구분 해 보겠습니다. 데이터베이스 모델링은 데이터에 관한 것이고 개체 모델링은 엔티티와 관계에 관한 것입니다.

Linq-to-SQL의 장점은 데이터베이스 스키마에서 클래스를 빠르게 생성하여 활성 레코드 개체로 사용할 수 있다는 것입니다 (활성 레코드 디자인 패턴 정의 참조).

NHibernate의 장점은 개체 모델링과 데이터베이스 모델링간에 유연성을 허용한다는 것입니다. 예를 들어 성능을 고려하여 데이터를 가장 잘 반영하도록 데이터베이스를 모델링 할 수 있습니다. 개체 모델링은 Domain-Driven-Design과 같은 접근 방식을 사용하여 비즈니스 규칙의 요소를 가장 잘 반영합니다. (Kevin Pang 의견 참조)

모델링 및 / 또는 명명 규칙이 좋지 않은 레거시 데이터베이스를 사용하면 Linq-to-SQL이 원하지 않는 구조와 이름을 클래스에 반영합니다. 그러나 NHibernate는 데이터 매퍼로 이러한 혼란을 숨길 수 있습니다.

데이터베이스의 이름 지정이 좋고 복잡성이 낮은 그린 필드 프로젝트에서는 Linq-to-SQL이 좋은 선택이 될 수 있습니다.

그러나 관례와 같은 매핑을 사용하여 이와 동일한 목적으로 자동 매핑과 함께 Fluent NHibernate 를 사용할 수 있습니다. 이 경우 XML 또는 C #을 사용하는 데이터 매퍼에 대해 걱정할 필요가 없으며 NHibernate가 사용자 정의 할 수있는 규칙에 따라 엔티티에서 데이터베이스 스키마를 생성하도록합니다.

반면에 Linq-to-SQL의 학습 곡선은 NHibernate보다 작습니다.

또는 Castle ActiveRecords 프로젝트를 사용할 수 있습니다.나는 레거시 프로젝트를위한 새로운 코드를 만들기 위해 짧은 시간 동안 그것을 사용 해왔다.그것은 NHibernate를 사용하고 활성 레코드 패턴에서 작동합니다 (내가 아는 이름을 감안할 때 놀랍습니다).나는 시도하지 않았지만 일단 사용했다면 NHibernate 지원으로 직접 내려야 할 필요성을 느낀다면 프로젝트의 일부 또는 전부를 그렇게하는 것이 너무 많지 않을 것이라고 가정합니다.

"둘 다 사용하지 않은 사람을 위해"라고 적었을 때 LINQ to SQL은 사용하기 쉬우므로 누구나 쉽게 사용할 수 있습니다. 또한 대부분의 시간에 도움이되는 절차를 지원합니다. 두 개 이상의 테이블에서 데이터를 가져온 다음 프로 시저를 작성하고 해당 프로 시저를 디자이너로 끌어다 놓으면 모든 것이 만들어집니다. 프로 시저 이름이 "CUSTOMER_ORDER_LINEITEM"이라고 가정합니다.이 세 테이블에서 레코드를 가져온 다음 작성합니다. 라코 디스

NHibernate에서 지원하지 않는 foreach 루프에서도 레코드 객체를 사용할 수 있습니다.

라이센스 : CC-BY-SA ~와 함께 속성
제휴하지 않습니다 StackOverflow
scroll top