0

私は4つのクラスを持っています:

  • 従業員 - 特定の従業員に関する情報を保持するフィールドのみが含まれます

  • EmployeeGroup - 従業員が行うことができる仕事の種類を説明するフィールドのみが含まれ、各従業員は EmployeeGroup クラスの 1 つに属します。

  • EmployeeDBase - データベースから従業員および従業員グループを追加または取得するためのメソッドが含まれています。

  • EmployeeForm - EmployeeDbase メソッドを使用して、Employee または EmployeeGroup フィールドを取得またはデータベースに追加します。また、フォームに情報を表示するための独自のメソッドもあります。

Employee と EmplyeeGroup の関係は集約であり、EmplyeeForm と EmployeeDBase の関係は依存関係にあると思います。Employee と EmployeeForm、Employee と EmplyeeDBase の関係は他にありますか (どちらも Employee オブジェクトを操作しているため)---

4

2 に答える 2

0

一般的に@Benjolに同意します。ここには2種類の関係があります。従業員<->EmployeeGroupは「ドメイン」関係です。つまり、問題空間のルールと特性を反映しています。したがって、標準の関連付けとしてモデル化するのが最も適切です。従業員が1つのグループのみのメンバーになることができる場合はmany：1、それ以外の場合はmany：manyです。正直なところ、集計にこだわる必要はありません。カーディナリティはより重要です。

他の関係は、ドメインソースではなくアーキテクチャです。それを個別に文書化します-できれば1つ以上のアーキテクチャパターンを参照してください。良い例については、MartinFowlerのカタログをご覧ください。

最後に、2つの観察：

  1. 説明から、デザインにはEmployeeFormとEmployeeDBaseのすべてのビジネスロジックを持つ単純な値オブジェクトとしてEmployeeとEmployeeGroupが含まれているように見えます。私は一般的に、ドメインロジックをドメインクラスから移動することを疑っています。それが正当化される場合があります-通常、本当に単純な/迅速なハックシステムの場合。ドメインロジックがuiまたはdbレイヤーにバインドされるのではなく、ドメインクラスでより適切にカプセル化されている場合、重要なドメインロジックがあるもの、および/または重要な寿命があると予想されるものは、通常、保守が容易です。（Eric Evansの「ドメイン駆動設計」を参照）。
  2. 「EmployeeGroup」は最もわかりやすい名前ではありません。あなたの説明から、それは「EmployeeRole」またはそれに類似した名前の方が良いでしょう。しかし、それは本で定義されているように見えるので、変更できるものではありません。
于 2010-09-14T07:46:20.837 に答える
0

あなたの質問は少し聞こえます... 理論的です。宿題に近い。

実際のエンティティを明確に表現した Employee および EmployeeGroup クラスと、アプリケーション内部のソフトウェア アーティファクトである EmployeeDBase および EmployeeForm を混同してはいけません。

于 2010-09-13T13:30:56.670 に答える