[linq] NHibernate와 LINQ to SQL

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

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

• StreetAddress
• 시티
• 상태
• 지퍼

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

• MailingStreetAddress
• 메일 링 시티
• MailingState
• MailingZip

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

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

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

답변