アプリロジック計画 — Tim Corey のアプローチをより深く見る

Tim CoreyのC# App Start To Finishシリーズでは、アプリケーションを構築することは単にコードを書くことではないと説明します。 本当の挑戦はアプリのロジックを計画することにあります——アプリケーションの異なる部分がどのように相互作用し、通信し、画面やコンポーネント間でデータを移動するか。 ログプランニングに焦点を当てたレッスン05では、全体としてアプリケーションがどのように動作するかを決定する段階であることを強調しています。

これまでに、コースではスコープ要件のカバー、全体構造の構築、データバックエンドの設計、フロントエンドの描画がすでに含まれていると振り返ります。 今、Timは言います、次のステップはロジックを通じてすべてを接続することです。

Timは、このレッスンではコードにまだ深く入らないと明言します。 代わりに、アプリケーションの背後にある全体的なアイデア、大きな絵、全体のロジックをカバーしたいのです。 彼は紙にメモを書き、各フォームやボタンがどのように振る舞うべきかをマッピングするために矢印を描くことを勧めています。これは、プロの開発環境でビジネスプロセスがマップされる方法と似ています。 この計画がコーディングに移る前にアプリロジックを明確にします。

ロジック計画の重要性

Timは、フォームを結線することがアプリケーションロジックの主要部分であると述べて開始します。 フォームが正しく接続されると、残りのタスクは通常小さくなります。 ロジック計画プロセスが、アプリケーションがサポートしなければならない機能、プロセス、およびコントロールを理解するのに役立つと説明します。

Timは、もしこれを紙でやるなら、各コンポーネントが何をすべきかを書き出し、それらの間に矢印を描くと言います。 クラスが画面上で作業しているとはいえ、彼は各フォームを歩き回り、各部分の背後にあるロジックを説明する予定です。

トーナメント作成フォームロジック

Timはトーナメント作成フォームから始めますが、これはより簡単なフォームの1つです。 各ボタンの背後にあるロジックと、それらがどのように協調して機能すべきかを説明します。

新しいチーム作成ボタン

Timは、新しいチーム作成ボタンがチーム作成フォームを開くと説明します。 チームが作成された後、新しいフォームが閉じられ、作成されたチームデータがトーナメント作成フォームに戻ります。 チームはチーム/プレーヤーリストボックスに表示されるべきであり、これはチーム作成フォームから呼び出されるメソッドを作成することで行われます。

Timはまた、フォームが直接お互いについて知らなくても相互作用できるようにインターフェースを使用するというコンセプトを紹介します。 これは、ビジネスロジックとソフトウェアアーキテクチャが一緒に機能し、コンポーネント間の品質、整合性、およびクリーンな相互作用を維持する方法の古典的な例です。

チーム追加ボタン

Timはチーム追加ボタンが簡単であることを説明します。 ドロップダウンで選択されているアイテムをチェックし、そのチームをトーナメントリストに追加し、ドロップダウンから削除してから、両方のリストをリフレッシュします。 このロジックは、ユーザーの選択がUIと基礎データで正しく反映されることを保証します。

賞作成ボタン

Timは賞作成ボタンが新しいチーム作成ボタンと同様に動作すると説明します。 それは賞作成フォームを開き、賞が作成されるのを待ってから、その賞を賞リストボックスに追加します。 ロジックは同じですが、クラスとデータ型が異なります。

選択された削除ボタン

Timは削除ボタンがリストボックスから選択されたアイテムを削除すると説明します。 チームの場合、ロジックは削除されたチームをもう一度ドロップダウンリストに戻し、ユーザーが後で再び追加できるようにします。 この種のリアルタイム更新はユーザーエクスペリエンスを向上させ、UI全体で正しいデータを維持するのに役立ちます。

トーナメント作成ボタン

Timはこれが多くのロジックをトリガーする大きなボタンであると説明します。 クリックされたとき、すべての情報を検証する必要があります。

• トーナメント名は空であってはなりません

• エントリー料金は負であってはなりません

• 少なくとも2チームが存在する必要があります

検証の後、Timは次の大きなステップ、スケジュールの作成を説明します。 トーナメントスケジュールのロジックは、トーナメントに何チームが参加すべきか、何名のバイが必要かを決定します。 Timは、この計算のために書いた公式をコンパニオンドキュメントで参照しています。 たとえば、トーナメントに10チームがある場合、トーナメントは16チームで開始しなければならず、最初のラウンドで6つのバイが必要です。

Timはまた、最初のラウンドの順序をランダム化する必要があることも指摘しています。 すべてが完了すると、フォームが完了し、アプリケーションは先に進めます。

チーム作成フォームのロジック

Timはチーム作成フォームに移り、そのボタンの背後にあるロジックを説明します。

メンバー追加ボタン

このボタンは、既存のメンバーをドロップダウンリストからチームリストボックスに追加するとTimは言います。 その後、そのメンバーをドロップダウンから削除し、両方のリストを更新します。 これは、チーム追加ボタンと似たロジックだとTimは強調します。

メンバー作成ボタン

Timはメンバー作成ボタンが4つの入力フィールドを受け取り、新しいチームメンバーを作成し、リストボックスに追加し、フィールドをクリアすると説明します。 これは、アプリケーションロジックの一般的なタスクの典型的な例で、ユーザー入力を処理し、UIに反映させる必要があります。

チーム作成ボタン

Timは、チーム作成ボタンがチームを検証し、作成されたチームを呼び出し元に送り返さなければならないと言います。 彼は、フォームに削除プレイヤーボタンが欠けており、他のフォームに合わせて追加し、一貫したユーザーエクスペリエンスを提供すべきであると述べます。 Timは、一貫したUIの動作がユーザーの親しみやすさと快適さにとって重要だと説明します。

賞品作成フォームのロジック

Timは賞品作成フォームをよりシンプルだと説明します。 それには4つのテキストボックスと1つのボタンがあります。

賞品作成ボタンがクリックされたとき、それは:

• 賞品情報を検証する

• データを呼び出し元のフォームに返します

• フォームを閉じます

このフォームは、コンポーネントが少ないものの、チーム作成と基本的に同じだとTimは説明します。

トーナメントダッシュボードのロジック

Timはトーナメントダッシュボードフォームをシンプルだが不可欠だと説明します。

それは既存のトーナメントを一覧表示します。 トーナメント読み込みボタンは選択されたトーナメントのためにトーナメントビューアを開き、トーナメント作成ボタンはトーナメント作成フォームを開きます。

トーナメントが作成されたときは、ユーザーが直ちにそれを読み込めるようにドロップダウンリストに追加しなければなりませんとTimは指摘します。 このロジックは、アプリ内でのデータアクセスとリアルタイム更新の基本的な例です。

トーナメントビューアのロジック

Timはトーナメントビューアを最も複雑なフォームと説明しています。これは最も多くのロジックを含むためです。

トーナメント名

トーナメント名はフォームを読み込む際に更新されるとTimは説明します。 このフォームはトーナメントオブジェクトを受け取り、名前を表示します。

ラウンドのドロップダウン

このドロップダウンはデータベースから読み込まれず、計算されているとTimは説明します。 それはラウンドのリストを見て、いくつ存在するかを決定します。また、トーナメントに4ラウンドがある場合、ドロップダウンはラウンド1からラウンド4までを表示しなければなりません。

未プレイのみのチェックボックス

このチェックボックスがチェックされている（デフォルト）場合、マッチアップリストボックスは未プレイのゲームのみを表示するためにフィルタリングされますとTimは言います。 チェックを外すと、すべてのマッチアップが表示されます。

マッチアップスコアセクション

Timは、マッチアップを選択すると右側のセクションがチーム名とスコアで更新されると説明します。 スコアボタンにより、ユーザーはスコアを更新し、マッチアップを確定できます。

次ラウンドのトリガー

最後の未プレイマッチアップがスコアリングされたら、次のラウンドが始まるべきだとTimは説明します。 それが最終のチャンピオンシップゲームの場合、トーナメントは終了し、賞品が割り当てられます。 システムは、予定があるときや結果が利用可能なときに参加者にメールを送信することもTimは指摘します。

スコア編集ルール

セットされた後にスコアを更新できるかどうか、それをTimは尋ねます。 彼は、それが可能だが、現在のラウンドがアクティブである間だけだと結論し、次のラウンドが始まった後にスコアが変更されると、チームが間違った相手とプレイする可能性があるため、大問題を引き起こす可能性があります。

したがって、スコアボタンにはスコアが現在のラウンド内でのみ変更可能であることを確認するロジックが必要だとTimは言います。

次は何?

Timは、例えば以下のように、まだ計画されていないロジックがあると認識しています。

• データアクセスとストレージ

• 異なるデータソースを処理する

• メールロジック

• マッチアップのトリガー

こういったものはコード内で計画されたほうがよく、チームはコーディングを始めたら取り組むつもりだと言います。 これは、ソフトウェア開発におけるビジネスの整合性の例であり、完璧に計画しないが、構築しながら適応するということです。

コードを書く前に計画することの結論

Timは、この動画の最後に、計画段階が完了したと述べます:

• データ設計が確定されました

• UIレイアウトが描かれました

• 各フォームの背後にあるロジックが計画されました

次のステップはこれをコードに翻訳することです。 次のレッスンでは、Timはクラスライブラリを作成し、デザインを実際のアプリケーションに実装し始めます。