ORM을 선택할 때 LINQ to SQL 또는 LINQ to Entities가 NHibernate보다 낫습니까?

Question

나는 Linq to Entities나 Linq to SQL을 사용하는 것보다 NHibernate, 심지어 Castle을 사용하여 더 많은 일을 할 수 있다는 것을 알았습니다.

내가 미쳤나요?

Answer 1

아니, 당신은 미친 게 아니다.nHibernate는 완전한 OR 매퍼이며, Linq to SQL 및 Linq to Entities는 OR 매퍼에서 기대하는 모든 것을 구현하지 않으며 약간 다른 개발자 그룹을 대상으로 합니다.

하지만 그렇다고 해서 Linq를 중단하지는 마십시오.Linq는 여전히 꽤 좋은 생각입니다 ..Linq를 사용하여 nHibernate를 사용해 보세요 :-)

Answer 2

NHibernate, Castle 등의 큰 단점은 정확히 가볍지 않다는 것입니다(특히 NHibernate).

Linq to SQL은 가볍고 제한된 사용 ORM에 적합합니다.

Answer 3

저는 NHibernate와 LINQ to SQL을 모두 사용했습니다.내 관점에서는 프로젝트에 따라 다르며 빠른 작업이 필요하면 L2S를 선택합니다. dbml 매핑을 생성하고 사용을 시작하는 것은 매우 간단합니다.보다 높은 수준의 엔터프라이즈 솔루션을 개발하는 경우에는 검증되고 신뢰할 수 있는 ORM인 NHibernate를 선택하겠습니다. 로깅 및 트랜잭션 기능은 사용이 간편합니다.

LINQ to SQL은 학습 곡선이 상대적으로 짧고 NHibernate는 학습 곡선이 훨씬 더 가파릅니다.

LINQ to SQL은 SQL Server만 지원하므로 Oracle 데이터베이스가 있는 경우 NHibernate라는 결정이 이미 내려졌습니다.

확인해 보시는 걸 추천드려요 http://www.summerofnhibernate.com/ NHibernate 학습에 대한 훌륭한 스크린캐스트를 위해.

Answer 4

명심해야 할 한 가지는 NHibernate가 구성하기에 절대적인 돼지가 될 수 있다는 것입니다. 특히 원래 Hibernate에 뿌리를 두고 있기 때문에 주로 XML 구성 파일을 기반으로 하기 때문입니다.

유창한 NHibernate 이것을 덜 고통스럽게 만드는 방법이 있습니다.

Linq는 확실히 .NET이 작동하는 일반적인 '방식'에 적합합니다.

Answer 5

Blockquote Linq는 확실히 .NET이 작동하는 일반적인 '방식'에 적합합니다.

아, 이런 감정이 겁이 나네요..net에 내장된 RAD는 닷넷의 작동 방식이 아니라 단지 프로토타입을 만들기 위한 도구 세트일 뿐입니다..NET을 사용하면 높은 수준의 응집력과 우려 사항의 분리를 통해 완전한 DDD 애플리케이션을 수행할 수 있으며 MS가 연결을 위해 시도하는 모든 노력에도 불구하고 분리된 코드를 작성할 수 있습니다.나는 .net이 결합되는 것을 좋아하고 특정 도구가 결합되는 것을 좋아한다는 점에 강력하게 동의하지 않습니다. 이 싸움에 SQL에 linq를 포함하겠습니다.linq to sql은 별도의 도메인 모델을 갖는 아이디어를 파괴합니다.내 데이터베이스 스키마를 기본 모델 개체로 사용한다는 생각에 겁이 납니다.적절한 ORM 도구를 사용하면 도메인을 먼저 모델링한 다음 관계형 데이터베이스를 이러한 모델에 연결할 수 있습니다.그 반대는 아닙니다.

Answer 6

나는 Entity Framework를 사용해 본 적이 없지만 Linq보다는 NHibernate를 SQL에 추천할 것입니다.제가 드릴 수 있는 가장 큰 이유는 바로 컨트롤입니다.Linq to SQL은 개체를 로드하고 개체에 대한 모든 종류의 추적 정보를 유지하면서 모든 것에 대해 훨씬 더 많은 제어권을 갖고 싶어합니다.직렬화/역직렬화를 하면 추적정보가 유실될 수 있으며, 다시 저장할 때 이상한 일이 발생할 수 있습니다.NHibernate는 저장소로서 더 잘 작동합니다. 원하는 개체(물론 이해하도록 구성한)가 무엇이든 전달하고, 수행한 작업에 관계없이 데이터베이스에 저장합니다.