1

すべてのプロパティが null 許容型でなければならないクラスがあります。新しいプロパティがnull許容型を持っていることを確認するために、Sessionsクラスプロパティの設計時(実行時ではない)の検証を追加することは可能ですか? プロパティに nulable 型がない場合、コンパイラはエラーを発生させ、コードをコンパイルしないようにする必要があります。

public class Sessions : SessionInfo<Sessions>
{
    public int? UserId { get; set; }
    public string FirstName { get; set; }
    public string LastName { get; set; }
    public string Email { get; set; }
    public string OldEmail { get; set; }
    public bool? UserManager { get; set; }
    public bool? UserManagerVisible { get; set; }
    public bool? TransactionCall { get; set; }        
}
4

2 に答える 2

1

int?最初は、例のみでbool?プロパティがnullableであるため、少し間違っています。Stringは参照型であり、(他の参照型と同様に) 受け入れることができますが、それ自体は ( C# という言葉の意味で) nullablenullではありません。

第 2 に、いいえ、コンパイル タイプでクラス定義を「チェック」する方法はありません。率直に言って、私には意味がありません。この制限がどこかにコーディングされると思いますか? では、最終的に手放すことにした場合はどうなるでしょうか。この「制約」コードを変更しますか? しかし、コードを編集するだけで解除できる場合、制限のポイントは何ですか? これは、鍵を保管するためだけにドアにロックを取り付けるようなものです。

はい、 Anders によって提案されているように、FxCop のような静的アナライザー ツールを使用してこれを回避できますが、私の観点からは、これの必要性はコードの設計上の問題を浮き彫りにします。このようなルールは通常、コード内の単一のクラスを制約するためではなく、プロジェクト レベルで特定の設計ポリシーを適用するために作成されます。

の役割が気になりSessionInfo<T>ます。Reflection で各プロパティを調べますか? 元の問題を説明していただければ、より良い解決策を見つけるお手伝いをいたします。また、 Curiously Recurring Template パターンの使用は、あなたが問題を解決しすぎるタイプの人である可能性を示唆しています。

何を達成しようとしていますか？

于 2011-08-08T12:06:06.460 に答える
0

まず、このためのカスタム FxCop ルールを作成します (ルールをハード コードしてセッション クラスのみをチェックするか、FxCop ルールが問題のクラスを見つけるために使用するカスタム属性を使用します)。以下は、ルールがクラス内のすべてのフィールドの命名をチェックする例です http://www.binarycoder.net/fxcop/html/ex_classfieldnameprefixes.html

ルールを作成したら、プロジェクトを右クリックして、[プロパティ] をクリックします。[コード分析] タブに移動します。「ビルド時にコード分析を実行する」にチェックを入れます。ルール セットにカスタム ルールが含まれていることを確認します。

これで、FxCop はプロジェクトの各コンパイルで静的コード分析を実行し、Visual Studio の [エラー リスト] タブにコンパイル警告と共に警告が報告されます。

于 2011-08-08T12:11:15.967 に答える