2

SOでこの質問を参照しました：

Entity Framework Code First を使用して読み取り専用の計算フィールドを保存する

彼らがしていることは理にかなっていますが、私は少し違うことを試みており、私の実装が適切かどうか、またはこれを行うためのより簡単な方法があるかどうかはわかりません:

public class AffiliateCommission
{
    public int Id { get; set; }
    public Merchant Merchant { get; set; }
    public AffiliateCommissionType Type { get; set; }
    public string Name { get; set; }
    public string Description { get; set; }
    public int Amount { get; set; }
    public string Status { get; set; }
    public DateTime RecievedDate { get; set; }
    public int TotalPaid { get 
    {
        if (Status == "Paid")
        {
            return this.Amount += this.Amount;
        }
        return 0;
    }
        protected set { }
    }


    public int TotalUnpaid
    {
        get
        {
            if (Status == "Unpaid")
            {
                return this.Amount += this.Amount;
            }
            return 0;
        }
        protected set { }
    }
    public int TotalInvoiced
    {
        get
        {
            if (Status == "Invoiced")
            {
                return this.Amount += this.Amount;
            }
            return 0;
        }
        protected set { }
    }
}

AffiliateCommissions のリストが作成される予定で、ステータスに基づいてすべてのコミッションの合計を取得したいと考えています。おそらく別のモデルに保存しますか？実装に関するアドバイスが必要です。

4

2 に答える 2

2

計算フィールドを永続化しようとしているのはなぜですか? プロパティの計算ロジックを使用すると、プロパティを一時的なもののままにして、毎回オンザフライで計算することができます。そうすれば、それを永続化する必要はありません。あなたの計算はそれほど高価ではないようです。このアプローチには、ビジネス ロジックが変更された場合でも、計算値が常に正確であるという利点もあります。

計算フィールドを永続化するユース ケースの 1 つは、データベースから直接取得するレポート作成です。この場合は、代わりに mapreduce クエリを調べることをお勧めします: http://en.wikipedia.org/wiki/MapReduce

于 2012-12-10T07:00:24.830 に答える
1

私はEFCodeFirstが好きですが、実際には「コードファースト」ではありません。通常、データベースにスキーマを作成し、EF CodeFirstPowertoolを使用してリバースエンジニアリングを行います。コードファーストは軽量ですが、データベースのアップグレードプロセス全体が開発と本番環境で苦痛を伴う可能性があるため、DBを昔ながらの方法で維持し、リバースエンジニアリングしてエンティティを取得する方が簡単であることがわかりました。

このアプローチを試して、SQL Serverで計算フィールドを作成し、それをリバースエンジニアリングして、どのコードが生成されるかを確認できます。

于 2012-12-10T12:55:45.830 に答える