NHibernate를 사용하여 다국어 도메인 객체를 구현하는 가장 좋은 방법은 무엇입니까?

Question

다국어 필드를 가질 수있는 도메인 개체를 디자인하는 가장 좋은 방법은 무엇입니까? 예를 들어 설명이 다국어 인 Product 클래스를 사용할 수 있습니다.

몇 개의 링크를 찾았지만 어느 것이 가장 좋은 방법인지 결정할 수 없습니다.

1. http://fabiomaulo.blogspot.com/2009/06/localized-property-with-nhibernate.html
   

2. http://ayende.com/Blog/archive/2006/12/26/LocalizingNHibernateContextualParameters.aspx
   

   는 (이 사람은 처음에 경고를 가지고 (우리는 SQL에서 쿼리 할 경우 하나 개의 필드에있는이 상점의 모든 지역화 된 언어 데이터는. 문제가 될 수 있습니다) 그것이를 더 이상 지원되지 않는 해킹입니다)

3. http://www.webdevbros.net/2009/06/24/create-a-multi-languaged-domain-model-with-nhibernate-and-c/
   (다국어 데이터가 어떻게 될지는 설명하지 않습니다. 데이터베이스에 구조화되어 있어야합니다.)

다국어 데이터와 함께 NHibernate를 사용해 본 경험이있는 사람. 더 좋은 방법이 있습니까?

Answer 1

세 번째 옵션은 멋지게 보입니다. 최대 절전 모드 매핑이 주어진다 있지만 데이터베이스 스키마 - 그건 당신이없는 거라면, 그럼 내가 여기 스케치 것이다 :

dictionary 
---------- 
ID: int - identity 
name: nvarchar(255) 

phrase 
------ 
dictionary_id:int (fkey dictionary.ID) 
culture_id:int  (LCID) 
phrase:nvarchar(255) - this is the default size - seems too small 

는 this blog entry에 따르면, 255 문자열 값에 대한 기본 문자열의 길이입니다. 문구 텍스트에 짧은 문자열 길이를 극복하기 위해, 당신은 당신의 도메인 모델이를 사용하려면, 당신은 당신이 번역 텍스트를하려는 기업에 PhraseDictionary 속성을 추가

<element column="phrase" type="String" length="4001"></element> 

에 <element> 태그를 변경할 수 있습니다. 예 : title 속성 또는 decription 속성

나는이 기사가 훌륭한 접근법을 설명하고 있다고 생각한다. 내가 갈 것 인 곳은 이다.

편집 : 의견에 대한 응답으로, 절대 최대 크기가 그보다 작은 경우 길이가 일반적으로 빠르기 때문에 4001보다 작게하십시오. 또한, NHibernate lazily 컬렉션을 가져올 것입니다,하지만 한 번에 모든 항목을 가져올 수 있습니다. 프로파일 링을 수행하여 이것이 성능에 영향을 미치는지 판별 할 수 있습니다. (소수의 언어를 사용하는 경우에는 차이점을 알 수 없을 것입니다.) 많은 언어 (Say 50+ 이상)가있는 경우 현지화 된 텍스트를 가져 오기 위해 사용자 정의 속성을 만드는 것이 유용 할 수 있습니다. 이들은 필요한 텍스트를 구체적으로 가져 오기 위해 쿼리를 발행합니다. 더 중요한 것은 별도의 쿼리로 각 지역화 된 텍스트 속성 대신 특정 쿼리의 특정 엔터티에 대한 모든 텍스트를 가져올 수 있습니다.

이 추가 작업은 프로파일 링으로 인해 성능에 대해 걱정할 필요가있는 경우에만 필요합니다. 문서의 구현이 적절하게 기능 할 가능성이 있습니다.

Answer 2

는 난 단지 최대 절전 모드에 대한 경험을 가지고 있지만 nHibernate 수는 매우 유사하기 때문에 :

하나의 옵션은 각 언어에 대한 회원들과 구성 요소 유형의 MultilingualString (이 시간 코딩에 알려진 언어의 집합을 가정)를 정의하는 것입니다. 이 유형은 언어 ID별로 문자열에 대한 getter를 배치하기에 편리한 위치입니다.오브젝트의 세계에서 표현이 잘 단위를 유지하면서 모든 언어에 대한 문자열 결과

class MultiLingualString { 
    String english; 
    String chinese; 
    String klingon; 

    String forLanguage(Language lang) { 
     switch (lang) { 
      // you can guess what goes here 
     } 
    } 
} 

은 데이터베이스에 별도의 컬럼에 저장된다.

장점은 문자열을 가져 오는 데 조인이 필요 없다는 것입니다. 반면에이 방법으로 문자열을 가져 오지 않는 유일한 방법은 투영법을 사용하는 것입니다. 이는 문자열이 크고 많지 않으며 거의 ​​필요하지 않은 경우 심각한 제한 사항입니다.

이 작업을 많이 수행하면 UserType을 작성하는 것이 좋습니다.

Answer 3

SQL Server에 대한 엄격한 데이터베이스 지향적 인 견해에서 모든 기본 데이터 (레코드 키, 날짜, 숫자 등)를 가진 하나의 테이블과 모든 변환 가능한 문자열 데이터가있는 하나의 테이블을 가져야합니다. Base와 Base_Description 두 테이블을 호출하자.

Base는 각 레코드에 대해 단일 키가 있음을 보장합니다. 키는 특정 사용 사례에 따라 문자열 또는 자동 생성 ID 일 수 있습니다.

Base_Description 테이블은 기본 테이블과 관련되어 있지만 데이터가 들어있는 언어를 선택하는 값도 포함되어 있습니다. 으로 연결 언어를 ​​설정할 수 있으므로 내 프로젝트에서 langid 열을 sys.languages부터 사용합니다. 대부분의 작업을 위해 @@ LANGID로 잡으십시오.

우리의 테스트에서 우리는 이것이 각 언어에 대해 여러 필드를 갖는 것보다 훨씬 빠르다는 것을 발견 했으므로 다른 언어를 더 쉽게 추가 할 수 있습니다. 우리는 또한 SQL Server Full-Text 인덱싱을 사용하고 있으며이 방법으로 완벽하게 작동합니다. 중립적 인 언어로 색인을 생성 한 다음 런타임에 검색 할 언어를 선택할 수 있습니다 (Base_Description의 LangID 열 필터링).

Answer 4

동일한 개체에 실제로 다중 언어 속성이있는 도메인 개체가 필요합니까? 그리고 만약 그렇다면, 오브젝트에 저장된 무제한 번역 (콜렉션에서 말하자면 어떤 마스터/디테일 또는 부모/자식 콜렉션과 같을 필요가 있다고 말합니다) 또는 고정 된 번역입니까? 그렇다면 어쨌든 정적으로 결정되어야하는 언어 (따라서 저장된 proc 또는 기타 결과의 매핑)는 무엇입니까?

내가 작업 한 많은 국제화 된 응용 프로그램에서 데이터는 고객 이름, 제품 이름 (하나의 국가에서 사용 된 동일한 제품조차도 다른 국가의 제품과 매핑 될 필요가 없었으며 다른 유통 업체 다른 SKU 및 물론 현지화 된 가격 책정). 인터페이스는 한 번에 하나의 언어로만 제공되었습니다. 따라서 모든 도메인 객체는 한 번에 하나의 언어 만 필요로했습니다. 따라서 번역 언어는 객체가 인스턴스화 될 때 결정됩니다.

번역 된 사용자 인터페이스를 사용하여 사용자가 번역 된 텍스트를 업데이트 할 수 있었지만 한 번에 2 개 언어 (로컬 및 기본값) 만 필요했습니다. 나는 이것이 당신이 말하는 것에 가장 가깝다는 것을 알 수 있습니다. 컬렉션에 가능한 모든 번역이 포함 된 번역 가능한 각 속성에 대한 하위 컬렉션을 가지고 있다고 생각합니다. 이것은 아마 당신이 링크 된 세 번째 기사의 두 번째 솔루션에 가장 근접 할 것입니다. 물론,이 시점에서 당신은 열망/게으른 로딩 등을 원한다면 볼 필요가 있습니다.