NHibernate 사용자 프로그래머들이하는 가장 일반적인 실수와 패턴은 무엇입니까?


28

NHibernate 사용자 프로그래머들이하는 가장 일반적인 실수와 패턴은 무엇입니까? 이것이 왜 나쁜 관행인지 설명하거나 더 읽을 수있는 자료를 제공하십시오.

예를 들면 다음과 같습니다.


1
현재 일반적인 실수의 일부를 찾을 수 있습니다 NHProf 경고

1
또한 여기에 대한 몇 가지 중요한 게시물이 NHibernate에주의 할 점은

답변:


34

내 개인 "자주 설명"문제 :

안티 패턴

와 장난 분리 된 객체 대신 DTO의를 사용 (될 saveOrUpdate 또는 병합 플러스 몇 가지 지저분한 코드). 엔티티가 복잡할수록 코드가 더 복잡합니다. (이것은 사소한 엔티티와도 잘 작동한다는 것을 의미합니다.) Ayende는이를 스트리퍼 패턴 이라고하며 캡슐화 문제를 설명합니다.

명시 적 SQL을 사용할 때와 같이 지속성 무지를 이해 하고 NH 응용 프로그램을 작성 하지 않습니다 . 그 증상 : 객체를 변경 한 후 Update를 호출하여 Update가 호출되지 않은 경우에도 변경 사항이 지속되는 이유를 궁금해하고 변경 사항이 유지되는 것을 피하는 방법이 궁금합니다.

거래작업 단위 패턴을 이해하지 못합니다 . 빈번한 안티 패턴 : 암시 적 트랜잭션, 작업 당 세션 및 응용 프로그램 당 세션. 더 읽을 거리 :

NH 이벤트 를 사용하여 애플리케이션 로직을 삽입 (예 : 삽입 및 업데이트 트리거의 변경 추적)

테이블 당 하나의 클래스를 만듭니다 . 어떤 사람들은 OOD를 이해하지 못하고 어떤 사람들은 관계형 디자인을 이해하지 못합니다.

실수

사용 일대일 대신 대일. 나는 이 답변 에서 설명하기 위해 그것을 시도했다 .

SetMaxResult와 함께 조인 페치 사용 해당 주제와 관련된 최신 답변 :

자체 변경 엔터티 작성 . 엔터티가 NH에 의해 설정된 값을 정확하게 반환하지 않으면 더티로 간주되어 모든 세션에서 업데이트됩니다. 예를 들어 : 속성 설정 기에서 NH 영구 컬렉션을 교체합니다.

  IList<Address> Addresses
  {
    get { return addresses; }
    // will cause the addresses collection to be built up from scratch
    // in the database in every session, even when just reading the entity.
    set { addresses = new List<Address>(value); }
  }

  int Whatever
  {
    // will make the entity dirty after reading negative values from the db.
    // this causes unexpected updates after just reading the entity.
    get { if (whatever < 0) return 0; }
    set { whatever = value; }
  }

더 많은 소식이 올 수 있습니다.


2
+1 : "작업 단위 패턴을 사용하지 않음"및 "응용 프로그램 당 하나의 세션"을 목록 imho에 추가해야합니다.
팔콘

@ 팔콘 : 아마. 일반적인 "트랜잭션 이해"문제입니다. 작업 단위는 지속성 무지에 의해 약간 커버됩니다. 그것들은 완전히 다른 개념이지만, 같은 패턴을 낳습니다.
Stefan Steinegger

5

" N + 1 문제 선택 "

여기에서 조작하려는 각 엔터티에 대한 선택 (N)을 선택하고 모든 엔터티와 해당 속성을 단일 선택하는 대신 엔터티 목록을 가져 오려면 선택 (+1)을 수행합니다.


1
  • 너무 많은 추상화
  • 자동 매핑을 사용하지 않는 경우 FluentNHibernate

첫 번째 요점은 약간 모호하지만 "리포지토리"또는 "DAO"뒤에 ISession을 숨기는 등 바보 같은 개념을 언급하는 경우 동의합니다.
chris

1
그러나 두 번째 요점은 말도 안됩니다. 실제 데이터 모델을 세밀하게 제어하고 도메인 모델과 분리 할 수있는 이유는 여러 가지가 있습니다. 결국, 그것은 "ORM"에서 "M"의 요점입니다. 자동 매핑을 사용하면 (간단한 시나리오에서는 유용하지만)이 방법을 사용하지 못합니다. 또한 자동 매핑이 쓸모없는 통합 레거시 데이터베이스 스키마 문제도 있습니다.
chris

기본 제공 코드 규칙 기반 매핑을 사용합니다. 그렇지 않으면 반복해야 할 쓰레기를 처리합니다. 그러나 여전히 컨벤션에 의해 생성 된 매핑에 대해 계층화되는 엔터티 별 사용자 지정에 대한 자유를 제공합니다. 매우 도움이됩니다.
Sam

1

나중에 Entity Framework (또는 다른 것)로 전환 할 수 있도록 추상화하려고합니다.

이것은 그것을 시도하는 대부분의 사람들보다 훨씬 어렵습니다. 둘 사이에는 수많은 미묘한 차이가 있습니다. 또한 결국에는 실제로 필요한 경우가 매우 드물기 때문에 접근 방식이 모두 잘못되었다는 사실을 발견하기 전에 몇 년 동안 세 심하게 구현하려고 시도 할 수 있습니다.

또한 2 단계 캐싱, 가로 채기, 동시성 관리, 변경 내용 추적, 프리 페치 쿼리 등과 같은 NHibernate의 유용하고 중요한 기능을 사용하지 못하도록 제한합니다.

NHibernate와 Entity Framework 사이를 전환해야 할 필요가 있다면 GitHub (아마도 CommonServiceLocator와 비슷한 맥락에서)를 지원하기 위해 적극적으로 개발 된 프로젝트가있을 것입니다.

당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.