N層アプリの開発。どの方向に？

Question

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

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

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

Answer 1

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

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

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

ただし、失敗したフィットネス テストから始めて、その機能に対して失敗した単体テストを作成し、スタックを遡って作業を進めると、最終的には非常に興味深い TDD サイクルが得られると言わなければなりません。場合によっては、データベース単体テストも作成しているため、Fitnesse テストが合格する前に、作成、失敗、合格する別のテスト層が存在します。

Answer 2

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

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

乾杯。

Answer 3

すぐに実用的な結果が得られるので、私はボトムアップで実行します。e.ユーザー インターフェイスなしで単体テストを作成することはできますが、モデルが完成するまでユーザー インターフェイスをテストすることはできません)。

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

Answer 4

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

それを考えると、おそらくすべてのレイヤーに何らかの更新を行う必要があるでしょう...=)