4

最低限、永続化可能なビジネス オブジェクトに組み込む必要がある機能は何だと思いますか?

例えば：

  • 検証
  • 同じタイプの別のオブジェクトと比較する方法
  • 元に戻す機能 (変更をロールバックする機能)
4

4 に答える 4

2

ドメインとビジネスによって決定される機能。

ドメイン駆動設計をお読みください。

于 2010-02-22T22:13:24.973 に答える
1

永続化可能なビジネス オブジェクトは、次のもので構成されている必要があります。

  • データ
  • 新しい
  • 保存
  • 消去
  • シリアル化
  • 逆シリアル化

多くの場合、機能を抽象化して、以下をサポートするリポジトリに取得します。

  • GetByID
  • すべて取得
  • GetByXYZCriteria

このタイプの機能をコレクション クラス (BusinessObjectTypeCollection など) にラップすることもできますが、これらのタイプのアクセサー (InvoicingRepository.GetAllCustomers、InvoicingRepository.GetAllInvoices など) を提供するために、ドメイン駆動設計でリポジトリ パターンを使用する動きが活発化しています。

ビジネス ルールを New、Save、Update、Delete ... に配置することもできますが、オブジェクトを渡す外部のビジネス ルール エンジンを使用することもできます。

于 2010-02-22T22:12:16.830 に答える
0

これは答えの 1 つにすぎませんが、このオブジェクトが関係を持つすべてのオブジェクトにアクセスする方法が必要であると言えます。最初は賢く、一部の関係に対して一方向のナビゲーション機能のみを含めるようにすることもできますが、これは通常、価値があるよりも面倒なことであることがわかりました。

すべての永続的なフレームワークには、ファインダー、カスケード削除を行う方法、並べ替えも含まれています。

モデリングを開始すると、すべてのビジネス オブジェクトが自分自身を管理する方法を知る必要があります。ビジネス オブジェクトを過度に参照している別のクラスを見つけた場合は、通常、その動作をビジネス オブジェクト自体にプッシュする必要があります。

于 2010-02-22T22:13:27.967 に答える
0

質問で指摘された 3 つのことのうち、本当に必要なのは検証だけだと思います。その他は、アプリケーションの全体的なアーキテクチャに依存します。

また、ビジネス ルールはビジネス オブジェクトに含まれている必要があります。

オブジェクトが独自のシリアル化を行うべきかどうかは興味深い問題です。私はこれまで、各オブジェクトに独自のシリアライゼーションを処理させることで大きな成功を収めてきましたが、シリアライゼーション モジュールがビジネス オブジェクトをロードし、GUI がオブジェクトから読み書きするのとまったく同じ方法でビジネス オブジェクトを保存することにも利点があると考えています。次に、検証により、データベースまたはファイルのエラーも保護されます。

一般的に必要なものは他に考えられません。

于 2010-02-22T22:22:21.253 に答える