2

UI (またはサービス ファサード) から DB までのすべてのレイヤーの変更を必要とするユーザー ストーリーを実装していると仮定します。

どの方向に移動しますか？

  • UIからビジネスレイヤー、リポジトリ、DBまで?
  • DBからリポジトリ、ビジネスレイヤー、UIまで?
  • 場合によります。（何の上に ？）
4

4 に答える 4

2

この種の質問に対する私が見た最良の答えは、Atomic Object の連中と彼らのPresenter Firstパターンによって提供されました。基本的に、これは (名前が示すように) プレゼンターから作業を開始する MVP パターンの実装です。

これにより、一連のユーザー アクションを直接モデル化できる非常に軽量なオブジェクトが提供されます (プレゼンターは基本的にモデルからビューにデータをマーシャリングし、ビューからモデルにイベントをマーシャリングするため)。プレゼンターで作業する場合、ビューとモデルは通常、インターフェイスとして定義され、モック化されるため、最初の焦点は、ユーザーがオブジェクトと対話する方法を定義することです。

厳密な MVP パターンを実行していなくても、通常はこの方法で作業するのが好きです。ユーザーとの対話に焦点を当てることで、より簡単に対話できるビジネス オブジェクトを作成できることがわかりました。また、社内での統合テストにもFitnesseを使用しています。ビジネス オブジェクトを構築しながら Fitnesse のフィクスチャを作成すると、ストーリーに対するユーザーの視点に焦点を当てることができます。

ただし、失敗した Fitnesse テストから始めて、その機能の失敗した単体テストを作成し、スタックを遡って作業を進めると、非常に興味深い TDD サイクルに終わると言わざるを得ません。場合によっては、データベース単体テストも作成しているため、Fitnesse テストが合格する前に、別のテスト レイヤーが作成され、失敗し、合格する必要があります。

于 2008-09-27T01:52:09.547 に答える
1

変更の可能性がある場合は、最前線から始めます。株主からのフィードバックをすぐに得ることができます。知るか？たぶん、彼らは自分が何を望んでいるのか、実際にはわかっていないのでしょう。インターフェース (UI、サービス、またはその他) の使い方を観察します。彼らの行動は、問題を新たな観点から見るきっかけになるかもしれません。ドメイン オブジェクトとデータベースをコーディングする前に変更をキャッチできれば、時間を大幅に節約できます。

要件が厳格であれば、それほど重要ではありません。最も困難である可能性が高い層から始めて、早期にリスクに対処します。結局のところ、これは「科学というより芸術」の問題の 1 つです。最適なソリューションを作成するのは、おそらくレイヤー デザイン間の微妙な相互作用です。

乾杯。

于 2008-09-25T17:31:52.030 に答える
0

問題のあるドメインのモデリングを開始します。システムのエンティティを表す関連クラスを作成します。それに自信が持てたら、エンティティをデータベースに永続化するための実行可能なマッピングを見つけようとします。ドメインのモデルを作成する前にUIに多くの作業を加えると、後でUIを再作業する必要があるという重大なリスクがあります。

それを考えると、とにかくすべてのレイヤーにいくつかの更新を行う必要があります... =）

于 2008-09-25T15:53:40.940 に答える
0

いくつかの作業結果がすぐに得られるので、ボトムアップで行います (つまり、ユーザー インターフェースなしで単体テストを作成できますが、モデルが完成するまでユーザー インターフェースをテストすることはできません)。

ただし、他の意見もあります。

于 2008-09-25T15:45:40.007 に答える