6

ビジネスオブジェクト、より具体的にはビジネスオブジェクトコレクションに頭を悩ませるのに苦労しています。

これが私がやろうとしていることの簡単な例です。

インシデントオブジェクトがある場合、このオブジェクトには多数の人が関与する可能性があり、それらの各人オブジェクトには複数のメモが含まれる可能性があります。メモはPersonオブジェクトなしでは存在できず、Personオブジェクトはインシデントオブジェクトなしでは存在できません。

Public List <Note> notes = new List <Note>（）がある場合、インシデント内のPersonはADDやREMOVEなどのメソッドを使用できるようになります。Notesコレクションでこれらのメソッドを呼び出すと、リストからメソッドが削除されるだけで、データソースから従業員を実際に追加/更新/削除するコードは実行されないと思います。これは私がリストを使うべきではなく何か他のものを使うべきだと私に信じさせますか？

これはまた私を別の質問に導きます。実際のデータベースCRUD操作はどこにあるべきですか。Noteオブジェクトには独自のCRUDが必要ですか、それとも、Personオブジェクトがそれなしでは存在できないため、Personオブジェクトがその責任を負う必要がありますか？

どちらに進むか迷っています。この部分はプログラムの残りの部分のテンプレートになるので、正しく理解したいと思います。

4

3 に答える 3

1

ここではいくつかの異なる質問があります。私が最も答えようとします。

使用する問題に関してはList<T>、フレームワークにはReadOnlyCollection<T>、まさにあなたの状況で役立つものがあります。これは、一度作成すると追加または削除できないコレクションです。

CRUDの運用責任に関しては、オブジェクトではなくデータレイヤーに属する必要があります（SRP-単一責任の原則を参照）。

于 2010-01-20T13:27:24.813 に答える
1

私のやり方は次のとおりです。子オブジェクトを持つ各オブジェクトにはそれらのリストが含まれ、親を持つ各オブジェクトにはそのタイプのプロパティが含まれます。追加は、オブジェクト（またはオブジェクトの階層）にデータを入力し、必要に応じて永続化のためにDALに送信することによって行われます。CRUD操作はすべてDAL内にあり、オブジェクトタイプに依存しませんが、そのようなタイプを使用して、アクセスするテーブルや列などを決定します。削除は、DALがオブジェクトを削除するようにトリガーするオブジェクトのDeletedプロパティを設定することによって異なる方法で処理される唯一のことです。

ビジネスロジックに関しては、オブジェクト自体（DAO）には存在しませんが、必要に応じてそのようなDAOを受信または収集し、作業を実行して、更新のためにDAOをDALに送り返すクラスによって実行されます。

于 2010-01-20T13:29:56.823 に答える
1

いくつかの素晴らしい情報が提供されていますが、あなたが混乱しているかもしれないとあなたが言ったことの1つはこれです：

「パブリックリストのメモ=新しいList（）がある場合、インシデント内のユーザーはADD、REMOVEなどのメソッドを使用できるようになります。」

それはすべて、クラスをどのように設計するかによって異なります。考慮すべきことの1つは、このデータが相互に関連する方法です。それはあなたがあなたのクラスのデザインを描くのを助けるでしょう。

次のように聞こえます。

  • 1つのインシデントに多くの人が関与する可能性があります
  • 1人でたくさんのメモを作成できます
  • メモは最低レベルであり、作成されたインシデントとそのインシデントに取り組んでいる責任者のために存在します。

インシデント1-多くの人

人1-多くのメモ

このタイプの関係は、さまざまな方法で実行できます。1つの方法は、関係するオブジェクトを実際に分離してから、結合されたオブジェクトを作成することです。

例えば

public class Incident {
//insert incident fields here
//do not add person logic / notes logic
//probably contains only properties
}

public class Person {
//insert person fields
//private members with public properties
//do not embed any other logic
}

public class Comment {
 //insert comment private fields
 //add public properties
 //follow the law of demeter
}

これらのクラスは相互に詳細を提供するのではなく、この情報を格納するための単なるリポジトリです。次に、これらのクラスを相互に関連付けます。

public class IncidentPersonnel {
List<Person> p;
//add methods to add a person to an incident
//add methods to remove a person from an incident
....
}

次に、担当者によるコメントを処理する別のクラスがある場合があります

public class PersonnelNotes {
List<Note> n;
//other methods...
}

あなたはこれをさらに進めることができますが、それは物事を複雑にするかもしれませんが、私はあなたにこれをどのように扱うかについての別の考えを与えています。

関数のデメテルの法則に従うようにしてください

すべてのオブジェクトをカプセル化します。さらに、隣人はあなたと話すことができますが、他のことはあまりできません...これにより、クラスの結合が緩くなり、思考プロセスが少し簡単になります。

最後に、CRUD操作がどのように機能するかについて説明しました。これはすべて、 DAL（データアクセス層）に戻ります。次に、テーブルからデータの行を返すのではなく、すべての属性を含む参照オブジェクトを返すことができます。追加と削除は同じように機能します（オブジェクトの受け渡し）。ORMを使用するか、独自のDALを作成できます。それはすべて、あなたが自分自身をどの程度関与させたいかによって異なります:)。

于 2010-01-20T13:47:52.960 に答える