3

クラスのモデリングと基礎となるデータベース設計について質問があります。

簡単に言えば、状況は次のとおりです: 現時点では、PositionsとAccountsのオブジェクトとテーブルがあり、それらの間の関係は、Position が Account 'has an' Account (Account は複数の Position を持つことができます) です。これは単純な集計であり、Account ID を外部キーとして保持する Position テーブルによって DB で処理されます。

これをTradesとPortfoliosで「下向き」に拡張する必要があります。1 つまたは複数の取引がポジションを構成し (ただし、取引自体はポジションではありません)、1 つまたは複数のポートフォリオがアカウントを構成します (ただし、ポートフォリオはそれ自体がアカウントではありません)。ポジションが口座に関連付けられているように、取引はポートフォリオに関連付けられています ('has a')。取引のないポジションとポートフォリオのないアカウントを持つことはまだ可能であることに注意してください (つまり、すべての既存のオブジェクトをサブコンポーネントに分類することは必須ではありません)。

私の最初のアイデアは、単純に次のようにすることでした (最初の 2 つのクラスは既に存在します)。

class Account;
class Position {
  Account account;
}
class Portfolio {
  Account account;
}
class Trade {
  Position position;
  Portfolio portfolio;
}

（潜在的な）問題は明らかだと思います。トレードから始めて、ポジション ルートを取るかポートフォリオ ルートを取るかによって、異なるアカウントになる可能性があります。もちろん、これは決して起こらないと想定されており、オブジェクトを作成して保存するコードは、そのような不整合を作成することはできません。矛盾したデータベースを持つことが理論的に可能であるという事実は、設計に欠陥があることを意味するのでしょうか?

フィードバックをお待ちしております。

4

1 に答える 1

0

クラスAからクラスDに移動する方法が2つあるという理由だけで、設計に欠陥はありません。1つはBを経由し、もう1つはCを経由します。このような「正方形」は、OOPクラスモデルによく表示されますが、特にパスにさらに多くのクラスがある場合は、それほど明白ではない場合があります。しかし、ダンが述べたように、常にビジネスセマンティクスは、そのような正方形が通勤する必要があるかどうかを決定します（数学的な意味で）。

=個人的には、UMLダイアグラムのそのような正方形の内側に、通勤する必要があることを示す標識を描きます。また、UMLコメントの正確な式に注意します。私の例では、次のようになります。

aクラスのすべてのオブジェクトに対してA：a.B.D = a.C.D

そのような述語が成り立つ場合、基本的に2つのオプションがあります。

  • それは非常によく文書化されているので、どのコードでもルールを破らないようにすべてのプログラマーを信頼してください
  • エラー処理（前述のDanやalgirdasなど）を実装するか、モデルにそのようなコードを含めたくない場合は、特定のモデルインスタンスのすべての条件をチェックするCheckerコントローラーを作成します。
于 2013-01-10T23:38:59.037 に答える