1

FluentnHibernateと自動マッピング機能を使用して小さなデータベースをモデル化したところです。今、私は検証をどのように扱うのか疑問に思っています。以前はクラスを属性で装飾していましたが、この慣例による自動マッピングの目的は、物事をクリーンに保つことです。

私はこのように見えるいくつかのオーバーライドファイルを持っています：

public class EventMappingOverride : IAutoMappingOverride<Event>
{
    public void Override(AutoMapping<Event> mapping)
    {
        mapping.Map(x => x.EventType, "TypeID").CustomType(typeof(EventType));
        mapping.Map(x => x.EventStatus, "StatusID").CustomType(typeof(EventStatus));
        mapping.HasMany(x => x.EventDates).KeyColumn("EventID");
    }
}

これは、検証ルールを配置する場所ですか？もしそうなら、それはどのように見えますか、そして自動マッピングを使用することへのポイントさえ本当にありますか（私のオーバーライドファイルがとにかく手の込んだものになる場合）？

ありがとう。

さらに明確にするために：

私のエンティティは今のところ次のようになっています。

namespace Business.Data
{
       public class Event
       {
            public virtual int Id { get; set; }
            public virtual string Title { get; set; }
            public virtual EventStatus EventStatus { get; set; }
            public virtual EventType EventType { get; set; }
            public virtual IList<EventDate> EventDates { get; set; }
       }
}

私は彼らをそのように見せ続けたいと思います。単なるオブジェクトなので、将来的にはORMを切り替えたりアップグレードしたりしても、これらのきれいなオブジェクトを使用できる可能性があります。

ただし、nHibernate Validator（NHContribの一部）を使用する場合、プロパティに属性を散らかさずに組み込む方法がわかりません。これはもっと質問のアーキテクチャだと思います。別の検証フレームワークを使用することもできますが、無効なレコードを挿入/更新しないように、nHibernateと連携させたいと思います。ご意見をいただければ幸いです。

4

1 に答える 1

2

私の意見は：

検証はビジネスの一部であり、検証はそれに依存し、データベースはこのニーズに合わせて拡張されます。したがって、dbに電子メール文字列列が必要な場合は、dbフレームワークに依存しないでください。特に、後でORMを切り替えると、作業が失われる可能性があります。

ビジネス/上位層で検証を維持し、dbに単純なクエリ/挿入を任せます。NHibernateはすでに少し複雑なので、単純に保ちます。

質問に答えるには、エンティティをポイ捨てしたくない場合は、ここで説明するようにxml検証を使用します。

http://nhforge.org/wikis/validator/nhibernate-validator-1-0-0-documentation.aspx

于 2012-05-29T20:56:04.317 に答える