NHibernateのマッピングの多くは、複数のソース

Question

背景

から来ると1対多の関係小さなレンガの壁。私は最後の日かそこそこの手がかりを探していたが、運がなかった。

私は次のように表と複数の他のテーブルとの間の関係をマップしようとしています：

親テーブルが表す「辞書を。」この辞書は、（ひどい）レガシーアプリケーションのアドホックレコードクエリで使用できるすべてのデータベースフィールドのリストです。各レコードには、アイテムが見つかる場所のテーブルと列、一意の識別名、グローバル値ルックアップテーブルで使用するキー、およびそれらのルックアップ値の引き込み方法を決定するフラグが格納されます。フラグ値が適切に設定されている場合、検索データを取得するために実行するSQL。テーブル名が[辞書]である（テーブル構造については下記を参照。）

フラグを有することができる4つの値のいずれか

• FREEFORM
• DYNAMIC
• STANDARD
• SYSTEM

フラグがFREEFORMに設定されている場合、エンドユーザーは必要な値を入力できます。それは他の値である場合は、次のように値をリストから選択する必要があります。

1. STANDARD：レガシー・アプリケーションは、唯一の違いということである二つの表の「UNION ALL」のクエリからのすべての値を引きます1つのテーブルは会計年度ベースであり、もう1つは「グローバル」値テーブルです。これらの表は、すべての「標準」フラグ付き辞書レコードのすべてのルックアップ値を保持します。これらの2つのテーブルはそれぞれ[fy_lookup_values]と[lookup_values]と呼ばれます（テーブル構造については以下を参照）
2. ：辞書テーブルのフレンドリ名が "state"の場合、状態]テーブル。国の場合は[country]テーブルと同じです（下の表の構造を参照）
3. ダイナミック：ルックアップ値は、前述のダイナミックSQLフィールドのクエリに基づいて読み込まれます。これらのクエリは、上記の他の2つのルックアップタイプの列名に似ていても、選択した列の名前を別名にすることはありません。以下のこれらのクエリで使用される多くのテーブルの1つの例を示します。

テーブル構造

Table [dictionary] 
    token int not null identity primary key 
    name varchar(10) not null 
    table_name varchar(50) not null 
    column_name varchar(30) not null 
    lookup_key varchar(10) not null 
    lookup_type varchar(8) not null 
    query_text text 

Table [lookup_values] 
    lookup_key varchar(10) not null primary key 
    lookup_value varchar(20) not null primary key 
    lookup_description text not null 

Table [fy_lookup_values] 
    lookup_key varchar(10) not null primary key 
    lookup_value varchar(20) not null primary key 
    lookup_description text not null 
    fy_year_token int not null 

Table [state] 
    state_code varchar(4) not null primary key 
    state_name varchar(30) not null 

Table [country] 
    country_code varchar(4) not null primary key 
    country_name varchar(50) not null 

Table [banks] 
    bank_token int not null identity primary key 
    bank_name varchar(50) not null 

アプリケーショングラブ内のルックアップ値retreivals二つの列、コードおよび説明のすべて。従来のアプリケーションは、現在、名前ではなく列の位置に基づいてすべての着信データをマッサージします。

私はデータベース構造に触れることはできません（ストアプロシージャを追加することさえできません）。また、いくつかのレガシーアプリケーションで使用されるルックアップの方法を変更することはできず、変更によって管理が非常に不幸になります...私はこのアプリケーションになると、これは私の髪を灰色にする多くの事の一つに過ぎないので、私ができることを望む。だから...

私の主な質問は、NHibernateでそうした方法でこれらをマッピングすることができるかどうかということです。そうすれば、辞書項目をつかむときに参照値が埋め込まれますか？それが可能なら、どうですか？私は、すべての検索が同じ方法で行われていれば、私はできますが、外部取得のクエリに基づいてマップできるかどうかはわかりません。

私の頭脳を包み込むのにはしばらく時間がかかりましたので、これは意味があると思います。

編集 私が達成しようとしていることのいくつかの例を以下に示します。

token, name  , table_name, column_name, lookup_key, lookup_type, query_text 
1 , gender , customer , gender  , gender , STANDARD , NULL 
2 , addr_st , customer , addr_st , state  , SYSTEM  , NULL 
3 , acct_type, cust_accts, type_code , acct_type , DYNAMIC , select type_code, descr from acct_types where active = 1 

だから、レガシー・アプリケーションでは、彼らを引き上げ取得するときに、ここで参照値をプルアップするために実行されるSQLです：

は、私たちは、[辞書]テーブルに次のレコードを持っています。

性別：

select lookup_value, 
     lookup_description 
from lookup_values 
union all 
select lookup_value, 
     lookup_description 
from lookup_values 
where fy_year_token = @P1 

住所状態：

select state_code, 
     state_name 
from state 

アカウントの種類：

select type_code, 
     descr 
from acct_types 
where active = 1 

Answer 1

あなたはサブクラス戦略を使用してこれを行うことができるかもしれません。したがって、ルックアップはLookupという抽象クラスから継承でき、table per concrete class strategyを使用してマップできます。辞書オブジェクトは、適切なキーを使用してルックアップのコレクションを持つことができます。

複雑なフェッチ戦略のおかげで、それぞれのルックアップに対して何らかの種類のcustom loaderを実装する必要があります。注意すべきことは、このローダはロードフェッチにのみ使用されることです。これらのルックアップに対してHQLまたは基準クエリーを作成する場合は、テーブルとマッピングに対して実行されます。しかし、うまくいけばそれをする必要はありません。