손으로 쓴 ADO/Sprocs와 nHibernate를 비교하기

Question

나는 nHibernate와 손으로 작성한 ado.net/저장 프로 시저를 사용하는 것 사이를왔다 갔다하고있다.

저는 데이터베이스 테이블을 매핑하는 간단한 클래스를 작성하고 내 데이터 레이어에 대한 내 저장 프로 시저와 데이터 레이어를 호출하고 객체를 반환하는 씬 비즈니스 로직 레이어를 래핑하는 템플릿을 사용하여 codesmith를 사용하고 있습니다. (1 개체 또는 컬렉션).

이 응용 프로그램은 온라인 커뮤니티 (기본적으로 포럼)에 사용되는 웹 응용 프로그램입니다.

지금 여름에 nhibernate 비디오를보고 있습니다.

nHibernate를 사용하면 내 인생이 쉬워 집니까? 데이터베이스 스키마에 대한 업데이트가 더 쉬워 질 것인가? 공연에 어떤 영향이 있을까요?

nhibernate를 설정하고 최적의 두통을 수행하는지 확인하고 있습니까?

복잡하거나 깊은 개체 모델을 원하지 않는다. 단순히 테이블을 매핑하는 클래스와 외래 키가있는 다른 테이블에서 데이터를 가져 오는 방법이 필요하다. 나는 매우 복잡한 OOP 모델을 원하지 않는다.

Answer 1

NHibernate는 특히 간단한 모델의 경우 매우 잘 작동합니다. 그것은 당신의 삶을 훨씬 쉽게 만들고 배우기가 너무 어렵지 않습니다. XML 매핑을 사용하는 대신 "Fluent NHibernate"를 보면 훨씬 쉽습니다.

Answer 2

NHibernate는 확실히 당신의 인생을 더 쉽게 만들 수 있습니다. ORM을 사용할 때 비즈니스 모델의 변경 사항을 충족하기 위해 데이터베이스 스키마를 리팩터링하는 것을 방해하는 저장 프로 시저 API가 없기 때문에 데이터베이스 스키마를 확실히 업데이트하는 것이 훨씬 쉽습니다.

OR 매퍼는 제공 할 LOT가 많으며 개발자 커뮤니티의 상당 부분과 거의 모든 DBA 커뮤니티가 오해하고 있습니다.

일반적으로 저장 프로 시저는 데이터베이스에서 성능을 튜닝하는 옵션을 더 많이 제공합니다. 출력을 변경하지 않는 한 저장 프로 시저를 자유롭게 다시 작성할 수 있기 때문입니다. 그러나 결과적으로 발생할 수있는 다른 문제로 인해 저장 프로 시저가 거의 다시 작성되지 않습니다 (예 : 새 버전의 소프트웨어를 배포 할 때 기존 procs의 수정 된 버전이 변경된 최적화 된 버전을 덮어 씁니다. 따라서 DBA에 의해 이익이 상실되고 유지 보수 및 예상치 못한 성능 문제가 발생합니다.)

또 다른 오해입니다 (주로 SQL Server 캠프에서 발생합니다 ... Oracle에 대한 경험이 거의 없음). 저장 프로 시저 (Stored Procedures)만이 컴파일되고 실행 계획이 캐싱 될 수 있다는 것입니다. SQL Server와 관련하여 모든 매개 변수가있는 쿼리는 컴파일되고 캐시 될 수 있습니다.

OR 매퍼의 장점은 저장 프로 시저에서 적응성이 있다는 것입니다. 저장 프로 시저를 사용하면 쿼리가 실행될 때 문맥에 관계없이 사용되는 단일 문을 작성하게됩니다. LINQ to SQL은 내가 본 것 중 가장 효율적인 쿼리를 생성 할 수있는 놀라운 능력을 가지고 있으며 종종 심각한 루프에 대해 DBA를 던졌습니다. 나는 L2S에 의해 생성 된 DBA의 질의를 보았습니다. 서브 쿼리와 비논리적 인 것들로 가득차 있으며 즉시 비웃었습니다. 그러나 문제가 있다고 가정하면 DBA가 작성한 쿼리의 성능 (즉, 물리적 읽기)이 현저하게 열등 해졌습니다. (때로는 DBA에 대한 L2 읽기와 물리적 읽기가 각각 30 회의 물리 읽기로 확장되었습니다.)

DBA의 관점에서 볼 때 ORM은 동적 SQL을 생성하기 때문에 이러한 쿼리를 최적화 할 수있는 방법이 없습니다. 반대로 SQL Server는 SQL Server에만 국한되며 SQL Server는 여러 가지 최적화 경로 (수평 및 수직 테이블 분할, 모든 테이블 또는 뷰에 대한 물리적 파일 배포, 인덱스 등)를 제공합니다. 쿼리를 수정해야 할 필요성이 제기됩니다. 쿼리를 수정해야하는 경우에도 SQL Server 2005 이상에서는 Plan Guides라는 명령을 제공합니다.이 가이드를 사용하면 모든 쿼리 (저장된 proc, strait SQL 등)를 적절하게 조정할 수 있습니다. 쿼리를 조정하는 것만으로는 충분하지 않은 경우 특정 쿼리를 전체 대체 쿼리와 일치시켜 DBA가 필요한만큼 쿼리를 조정할 수 있습니다. (최후의 수단으로 사용하십시오.)

OR 매퍼를 사용하면 얻을 수있는 많은 이점이 있으며 NHibernate는 무료입니다 (LLBLGen도 훌륭하지만 무료는 아닙니다.) LINQ to Sql 및 Entity Framework는 Microsoft의 새로운 제품입니다 (L2S는 곧 .NET 4.0 프레임 워크에서 EF 4.0으로 대체 될 예정입니다 ... ORM을 채택하는 데있어 가장 큰 장애물은 일반적으로 ORM 제품 자체도 아니며 기능 또는 공연. 가장 큰 장애물은 일반적으로 귀하의 DBA를 (귀하의 행운/불행에 달려 있습니다 ... 귀하의 경험에 달려 있다면 ...) ORM이 DBA의 최적화 경로 비용없이 효율성을 향상시키고 유지 보수 비용을 줄일 수 있다는 것입니다.