テーブルの主キーに Guid.comb を使用しています。
ドメイン クラスの ID として null 許容の GUID を使用しているサンプルは見つかりませんでした。これはNHibernateの悪い習慣ですか?
理由: POCO のリストをコンボ ボックスにバインドしています。null 可能な GUID がない場合、DataAnnotations Required Validation でデフォルト ビルドを使用する代わりに、Guid.Empty の検証を処理する必要があります。
ありがとうございます
主キーの主な理由は、特定のレコードの一意の識別子を定義することです。主キーを null 可能にできる場合、NHibernate は空の GUID を持つ新しく作成されたレコードと、空または null 可能な GUID を持つデータベース内の既存のレコードとの違いを区別できません。
そうです、これは非常に悪い習慣であるため、この例はありません。
POCOをコンボボックスにバインドする例に関しては、これも悪い習慣です。関心の分離の原則に従って、UI ロジックを、データベースに永続化するために NHibernate で使用している POCO/エンティティなどのドメイン固有のロジックと混合したくないでしょう。通常、UI に必要なデータを格納する ViewModel クラスを作成します。次に、ビジネス ロジックを格納し、ViewModel クラスを POCO/エンティティ/DTO に変換/マッピングするサービス/ビジネス レイヤーを作成します。
したがって、あなたの例では、アプリケーションが懸念の分離の原則に従っている場合、NHibernate を使用して作成/保存/更新するオブジェクトを公開しないため、直面している問題に遭遇することさえありません。このようにアプリケーションを分離すると、データベース アーキテクチャを UI に直接結び付けない、他のレイヤーに劇的な影響を与えることなく UI、サービス レイヤー、またはデータベースを簡単に変更できるなど、他の多くの利点が得られます。