問題タブ [backing-field]

次のような構造体があるとします。

もちろん、The 'this' object cannot be used before all of its fields are assigned toというコンパイラ エラーが生成されます。

バッキング フィールドまたはプロパティ自体に値を割り当てる方法はありますか? または、独自の明示的なバッキング フィールドを使用して昔ながらの方法でプロパティを実装する必要がありますか?

base _photos フィールドを指すようにマッピング クラスのアクセス戦略を設定するにはどうすればよいですか?

現在、次を使用してバッキング フィールドを見つけようとしていますが、見つからないため例外がスローされます。

バッキングフィールド _photos をクラスに直接移動してみましたが、アクセスは機能します。では、基本クラスのバッキング フィールドにアクセスするにはどうすればよいでしょうか。

独自のフィールドとプロパティでクラス内で作業する場合、通常、プロパティを使用するのは、何らかの機能 (値の制限や検証など) を実行するときだけです。それ以外の場合は、バッキング フィールドを直接読み書きすることを好みます。

私はどういうわけか、これが物事を行うためのより一般的にパフォーマンスの高い方法であると頭に浮かびましたが、この考えを裏付ける証拠が実際には何もないことに気づきました。

慣習や好みは別として、一方の方法と他方の方法の間に実際のパフォーマンス要因はありますか?

のドキュメントAccess.BackingField()は、これを示しています。

自動プロパティのバッキングフィールドを使用するようにアクセス戦略を設定します。

自動プロパティがバッキングフィールドでコンパイルされることは理解していますが、プロパティが定義上バニラゲッター/セッターである場合、セッターを使用する（つまり、FNHのデフォルトを使用する）のではなく、バニラフィールドに直接移動することでどのような利点が得られます。

私が考えることができる唯一のことは、誰かが後でセッターにロジックを追加した場合にマッピングを壊したいと思うかもしれないということです。

私は何が欠けていますか？

内部の DoubleAnimation オブジェクトを介して子をアニメーション化するカスタム パネル クラスがあります。ただし、アニメーションの Duration 依存関係プロパティをパネルのパブリック プロパティとして公開して、ユーザーがパネルを使用するときに XAML で変更できるようにします。しかし、アニメーション オブジェクトの他の部分は公開したくありません。持続時間だけです。

私に提案され続けている最初のことは、PropertyChanged 通知を使用することですが、それはゲッターではなくセッターに対してのみ機能します。また、XAML は .NET プロパティを完全にバイパスするため、単純に .NET プロパティを作成することもできません。

私の同僚は賢い考えを持っていました... 外部プロパティと内部オブジェクトのプロパティの間で双方向のデータ バインディングを使用します。ただし、データバインディングは別として、これを行うための別の/より良い方法はありますか...それを含むオブジェクトのパブリックインターフェイスを介して内部オブジェクトの依存関係プロパティを公開しますか?

更新しました：

双方向の DataBinding が最適だったようです。（@Jeffに感謝します！）そのために、外側のDPをセットアップする最良の方法であることがわかったので、メタデータ、デフォルト、およびすべてが内側のオブジェクトのDPに完全に一致します。次に、Jeff のバインディング トリックを使用すれば完了です。

私はクラスを持っています：

' IList<string> ChildPages'がFluentNHibernateによって自動マップされると、コレクション内の各文字列のバッキングフィールドを使用して' ChildPages'結合テーブルが作成されます。nvarchar(255)

しかし、問題は、SQLバッキングフィールドを' text'にしたいので、このエンティティの長いエントリを持つことができるということです。

この変更を行う最も簡単な方法は何ですか？

自動マッピングされたプリミティブコレクションの基になるタイプをどのように変更しますか？

また、追加のポイントについては、規則またはマッピングのオーバーライドを使用してこれをどのように行いますか？

どうも！

次のような単純なプロパティを整理するのが好きです。

私はStyleCopで遊んでいますが、コンストラクターの後にフィールドを配置すると怒鳴られます。フィールドがプロパティの外部で参照されない限り、このスタイルは一般的に受け入れられますか? 注：個人的な好みがあることは承知していますが、この問題に関して一般的なコンセンサスがあるかどうか疑問に思っています.

私は、学生と教授（_students_selected）の間のデータベース（ブリッジテーブルを使用）でモデル化されたマントツーマンの関係を持っています。私の全体では、1対多の関係としてモデル化しています。つまり、教授には1人の学生がいます。

上記はデータを取得するときに機能しますが、教授にクエリを実行する場合、実際のデータはプライベートバッキングフィールド_studentsにマップされているため、学生にwhere条件を追加できません。これをクエリするにはどうすればよいですか？以下のコードは機能しません。

いくつかのケースでは、私は実際的な理由で「バッキングプロパティ」を必要とするプロパティを持っています。

たとえば、Nameプロパティを持つ1つのタイプがあります。アクセス時に発生する値の変換はなく、ある種のアクションをトリガーするだけです。あなたがそうするなら、副作用。（議論のために重要であるというわけではありませんが、この特定のケースでは、名前は変更されたときに別の場所にコピーされます。）

まあ言ってみれば：

したがって、「_ name」プロパティはデータベースにマップされますが、直接変更できないように保護/内部的に保持されます。そして、2番目のパブリックプロパティ「Name」が実際のアクセスを提供します。

私がこのように設定した理由は、そのアクションがマップされた「_name」プロパティのset-methodに直接組み込まれている場合、オブジェクトがデータベースからハイドレイトされたときにトリガーされるためです。これは私が望んでいることではありません。

これはすべて問題なく機能します。

問題は、このタイプをクエリする必要がある場合、そのプロパティがマップされていないため、Person.Nameをクエリしようとしても機能しないことです。

私がこれについて嫌いなのは、Person.Nameに対してコードを記述しているが、Person._nameに対してクエリを記述しなければならないという事実です。これは、エラーが発生しやすく、混乱を招きます。

この問題を解決するためのより良い方法はありますか？

C＃ではType.GetFields()、派生クラスを表す型で使用すると、a）派生クラスで明示的に宣言されたすべてのフィールド、b）派生クラスで自動プロパティのすべてのバッキングフィールド、c）ベースで明示的に宣言されたすべてのフィールドが返されます。クラス。

d）基本クラスの自動プロパティのバッキングフィールドが欠落しているのはなぜですか？

例：

これは、Fooではなく、Barのバッキングフィールドのみを表示します。