1

私は、すべてのフィールドを含め、すべての取得/設定プロパティを記述し、すべてのデータベース呼び出しを行う別のデータベース クラスを作成する必要があるプロパティ クラスを作成することに慣れています。

Properties Class
    private int _intCard
    public int IntCard
    {
        set { _intcard = value;}
    }
Constructor here

扱うプロパティが 120 を超えており、これらのプロパティを 1 つずつ書き出さなければならないのは非常に時間がかかるため、現時点ではこれは適切なアプローチとは思えません。プロパティのいくつかに検証を追加する必要があるのは、この方法を選択した理由です。set メソッドで検証できます。同じ結果を完成させるために私が調べることができる別の方法を誰かが提案できますか?

********************---------------*******************

したがって、コメントを与えると、私の設計に欠陥があることがわかり、それがこの質問に来ると考えました。これを修正する方法については考えがありますが、これが正しいアプローチかどうかはわかりません。私は Object Design Principles を検索し、それを読みましたが、それが私に教えていることを理解するにはもっと時間が必要です. 今のところ、このアプローチが正しい方法であるかどうかを知りたい

申請者の名前、住所、電話番号、ファックス番号、携帯電話番号、代替電話番号、代替住所、配偶者と同じ、そして子供、参照、会社情報などを追跡しています。

嘘をつくつもりはありませんが、これを実装するためにまだ抽象クラスを理解していません。

プロパティ クラスは次のようになります。

これは私がやるべきことの線に沿っていますか?

再度、感謝します

4

6 に答える 6

5

あなたのオブジェクト モデリングが正しくないと思わずにはいられません。120 個のプロパティを持つクラスがある場合、そのオブジェクトを個別の役割/責任などに分割していません。作成するクラスの数を (劇的に) 増やすことを検討すると、ソリューションがより管理しやすくなります。

これにより、処理する必要のあるプロパティの数が減ることはありません。不変オブジェクト (構築中にこれらのプロパティを設定する必要がありますか?)、および/または構築を支援するビルダーパターンの使用を検討する価値があるかもしれません。

最後に、これらのプロパティを公開する必要がありますか? OO の重要な部分は、オブジェクトの内容を取得してオブジェクトに代わって処理を行うのではなく、オブジェクトに処理を指示することです。オブジェクトに何かを行うように指示できる場合、(内部) フィールドを公開する必要はほとんどありません。

于 2013-02-13T12:37:44.903 に答える
0

これは設計上の問題に対処するものではないことに注意してください。データベースがsql-server上にある場合、入力を避けるために、次のようなクエリを使用して(要件に合わせて変更してください)、データ型を含むプロパティリストを取得し、結果をコピーして貼り付けることができます。SQL SERVER DEMO

SELECT  'public ' + CASE DATA_TYPE WHEN 'smallint' THEN 'short' 
                WHEN 'bit' THEN 'bool'
                WHEN 'smalldatetime' THEN 'System.DateTime'
                WHEN 'datetime' THEN 'System.DateTime'
                WHEN 'date' THEN 'System.DateTime'
                WHEN 'uniqueidentifier' THEN 'System.Guid'
                WHEN 'varchar' THEN 'string'
                WHEN 'int' THEN 'int' 
                WHEN 'numeric' THEN 'decimal'
                ELSE DATA_TYPE END 
          + CASE IS_NULLABLE  WHEN 'NO' THEN '' ELSE '?' END
          + ' ' + COLUMN_NAME 
          + ' { get; set; }' AS def
FROM INFORMATION_SCHEMA.COLUMNS 
WHERE TABLE_NAME = 'YourTableName'
ORDER BY IS_NULLABLE, ORDINAL_POSITION
于 2013-02-13T12:47:04.343 に答える
0

ティム、

あなたの編集に基づいて、あなたは正しい線にいるように見えます. プロパティを特定の項目に分割する必要があります。次に例を示します。

public class Person
    {
        public string GivenName { get; set; }
        public string Surname { get; set; }
        public ContactInfo ContactInformation { get; set; }
    }

public class Applicant : Person
    {
        public Person Spouse { get; set; }
        public List<Person> Children { get; set; }
        public List<Reference> References { get; set; }
    }

public class ContactInfo
    {
        [Required]
        [DataType(DataType.PhoneNumber)]
        public string PhoneNumber { get; set; }

        [DataType(DataType.EmailAddress)]
        public string EmailAddress { get; set; }

        public Address PrimaryAddress { get; set; }
        public Address AlternativeAddress { get; set; }
    }

ここで重要なポイントは

  1. クラスは、管理可能で再利用可能なチャンクに分割されます
  2. データ注釈 (ContactInfo クラスの必須および DataType) は、プロパティの検証に使用されます
  3. プロパティは明示的なプライベート変数を必要としなくなりました

PS データ注釈に関するもう少し詳しい情報: http://msdn.microsoft.com/en-us/library/dd901590(v=vs.95).aspx

于 2013-02-13T15:51:00.180 に答える
0

最新の c# バージョンには、プロパティ用の非常にコンパクトなシンタックスがあります。

public class Properties {
    public int IntCard { get; set; }
}

ここでは、c# がプライベート変数を処理するため、多くのキーストロークを回避できます。検証には、 Data Annotationsを使用できます。詳細はこちら

それが役に立てば幸い

于 2013-02-13T12:45:19.913 に答える
0

コメントを読むと、次のような少なくとも 2 つのクラス Person、Address が必要なようです。

public class Person 
{
  Guid Id {get; set;}
  string Name {get; set;}
  // ad infinitum the truely unique things that relate to an Individual

  Address BusinessAddress {get; set;}
  Address HomeAddress {get; set;}
  Person Spouse {get; set;}
}

public class Address
{
  Guid Id {get; set;}
  Line1 {get; set;}
  // ad infinitum all the truly unique things that relate to an address
}

上記は本質的に疑似コードであり、「これがまさにその方法です」と読むべきではありません。たとえば、プロパティがプライベート/パブリック/保護されているかどうか、または実際にコンストラクターを提供しているかどうかについては述べていません。

しかし、他のクラスをプロパティとして使用する方法を示しており、「配偶者」の場合、非常に豊富で深いオブジェクト階層を作成できます (配偶者には、アドレスと潜在的に別の配偶者を含めることができます-循環参照アホイ!)コードをより読みやすくし、「概念/エンティティ/ドメイン」を「その特定のもの」にすることが仕事である単一のユニットにカプセル化するコードの責任を分離します。カプセル化、継承などの OOP の概念 (基本的には OO の 4 つの教義) を見て、オブジェクトが何を表す必要があるかを理解する価値があると思われます。クラスを作成し、より便利なオブジェクトを構築します。

http://codebetter.com/raymondlewallen/2005/07/19/4-major-principles-of-object-directional-programming/

于 2013-02-13T15:56:28.833 に答える
0

@brian-agnew に完全に同意します。1 つのクラスに非常に多くのプロパティがある場合は、ほぼ確実に懸念事項を十分に分離できないため、何らかのリファクタリングを行う必要があります。

ただし、リファクタリングを行った後でもプロパティは残っているため、データ検証属性を調べる価値があります。たとえば、MVC でそれらを使用するウォークスルーは次のとおりです。 cs . 次に、自動実装されたプロパティを使用できます。

public int IntCard { get; set; }
于 2013-02-13T12:51:32.167 に答える