3

更新：これはできないことを知っていることに注意してください...これは私が本当にうまくいくことを望んでいたことです。責任を分離する他の方法があるかもしれませんね。だから私が探しているのは...

Entity Framework は、複数の責任をクラスに強制します (通常のロジック、基本的な注釈、および CRUD インターフェイス機能)。通常はすべて 1 つのクラスにあるものを取りたいだけです...そして、Entity Framework と通常のロジックを介してクラスの永続的な機能を分離します。

私の思考プロセス: 最近、私は Entity Framework に取り掛かっていますが、いくつかのエンティティ クラスがやややりすぎているという考えは好きではありません。ロジック、データ アクセスとのインターフェイス、および Entity Framework 注釈。これを修正するために、Entity クラス ファイルを部分的に作成し、クラスの他の側面から離れた場所にデータ アクセス機能を実装したいと考えました。これはうまく機能し、非常にきれいです！

そうしているうちに、プロパティを部分的にして、EF プロパティ アノテーションから離れた場所に実装することが非常に有益であると考えました!! これにより、ファイルがクリアされ、単一の責任が許可されます。ただし、これは許可されていません。残念。

部分プロパティは、部分メソッドと同様に実装されます。1 つの部分プロパティの定義と、もう 1 つの部分プロパティの実装...上部のリンクの写真 (またはコメント) とその下のコードのように。

public partial class Agency : PropertyValidator, IAgency
{
    private string _name;

    public partial string Name 
    {
        get { return _name; }
        set
        {
            // PropertyValidator stuff
            if (string.IsNullOrEmpty(value))
                AddErrorToProperty("Agency name must contain a reasonable alphanumeric value.");
            if (string.IsNullOrWhiteSpace(value))   
                AddErrorToProperty("Agency name cannot contain all spaces.");

            SetPropertyIfValid(ref _name, value);
        }
    }
}

次に、すべての抽象データベース項目を処理する他の部分クラスがあります...

public partial class Agency : IPersitentEntity, IAgency
{       
    [Key]    // NOTE these Annotations are because of Entity Framework...nice separation! 
    public int ID { get; set; } // From IPersitentEntity

    [Required]
    [MinLength(3), MaxLength(50)]
    public partial string Name { get; set; } // IAgency NOTE this is not valid, but the 
                                             // separation is amazing!

    // From IPersitentEntity provide CRUD support
    public void Create() { throw new NotImplementedException(); }
    public void Retrieve(int id) { throw new NotImplementedException(); }
    public void Update(int id) { throw new NotImplementedException(); }
    public void Delete(int id) { throw new NotImplementedException(); }
}

現在、注釈とロジックを組み合わせる必要があります。EF 注釈を除いて、抽象データベース項目を既に分離しているので、ちょっと奇妙です!

4

2 に答える 2

8

プロパティが存在しない理由の 1つは、メンバーpartialの基本的な設計哲学に適合しないことです。partial目標は、必要に応じてコード ジェネレーターが追加のロジックをプラグインできるスタブを単純に定義することです。生成されたコードがメソッドを埋めていない場合、スタブへのすべての呼び出しがpartial最終的なプログラムから削除されます。

この目標を達成するために、partialメソッドには を返さなければならないなど、いくつかの制限がありvoidます。これにより、削除された場合に残る値がないため、コンパイルが非常に簡単になります。

SomePartialMethod();

一方、プロパティは になることはできませんvoid。具体的なタイプでなければなりません。したがって、ユーザーはいつでも次のように書くことができます

string x = SomePartialProperty;

これをコンパイラが完全に消去することは不可能です。この式は何らかの値を代入する必要があり、xそれ以外の場合、プログラムは単にコンパイルできません。これを機能させるには、コンパイラは の適切なデフォルト値を選択する必要がありますx。確かにこれは可能です (たとえばdefault(T)、この機能を持たないという決定にこれが考慮されたと思います.

于 2013-08-22T06:09:58.447 に答える
1

主にpartialコード生成用ですが、自分の個人プロジェクトでの小さなレベルの分離を容易にするためにコードベースを変更することはお勧めできないと判断した、クラス内のさまざまな責任を分離すると便利であることがわかりました。現場でそれが行われたのを見たことがありません...コード生成以外にも。

これが個人的なプロジェクトかどうかはわかりませんが、そうであれば、永続的なアイテムを分離する必要があるように、パーシャルを使用するだけです。データベース コードとビジネス ロジックの間に別のレベルを作成することで、これをさらに分離する Web サイトを見てきました。これを実装したことがない場合、実装は負担になる可能性があり、プロジェクトに大量のクラスが追加されます。

これが個人的なプロジェクトである場合、それは価値がない可能性があり、さまざまな責任を「分離」したい場合は、部分クラスがうまくいくようです。データへのアクセス方法を変更する必要がある場合は、その部分クラスのみを変更し、通常のビジネス ロジックには触れません。

[編集] しかし、おそらくプロパティの注釈の分離が見当たらないでしょうが、私は疑問に思います...

永続部分クラスでプロパティを宣言し、通常のビジネス ロジック部分クラスで getter および setter プライベート メソッドを呼び出した場合!?!? このようにして、ロジックはその1つの部分クラスにあり、注釈は必要な他の部分クラスにあります

于 2013-08-24T02:51:06.007 に答える