NHibernate 사용자 프로그래머들이하는 가장 일반적인 실수와 패턴은 무엇입니까? 이것이 왜 나쁜 관행인지 설명하거나 더 읽을 수있는 자료를 제공하십시오.
예를 들면 다음과 같습니다.
답변:
내 개인 "자주 설명"문제 :
와 장난 분리 된 객체 대신 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; }
}
더 많은 소식이 올 수 있습니다.
" N + 1 문제 선택 "
여기에서 조작하려는 각 엔터티에 대한 선택 (N)을 선택하고 모든 엔터티와 해당 속성을 단일 선택하는 대신 엔터티 목록을 가져 오려면 선택 (+1)을 수행합니다.
FluentNHibernate나중에 Entity Framework (또는 다른 것)로 전환 할 수 있도록 추상화하려고합니다.
이것은 그것을 시도하는 대부분의 사람들보다 훨씬 어렵습니다. 둘 사이에는 수많은 미묘한 차이가 있습니다. 또한 결국에는 실제로 필요한 경우가 매우 드물기 때문에 접근 방식이 모두 잘못되었다는 사실을 발견하기 전에 몇 년 동안 세 심하게 구현하려고 시도 할 수 있습니다.
또한 2 단계 캐싱, 가로 채기, 동시성 관리, 변경 내용 추적, 프리 페치 쿼리 등과 같은 NHibernate의 유용하고 중요한 기능을 사용하지 못하도록 제한합니다.
NHibernate와 Entity Framework 사이를 전환해야 할 필요가 있다면 GitHub (아마도 CommonServiceLocator와 비슷한 맥락에서)를 지원하기 위해 적극적으로 개발 된 프로젝트가있을 것입니다.