効率を維持しながら、ビジネスロジックからユーザーインターフェイスを分離するにはどうすればよいですか？

コンボボックスで10個の異なるオブジェクトを表すフォームを表示したいとします。たとえば、トマトを含む10種類のハンバーガーのうち1つをユーザーに選択してもらいます。

UIとロジックを分離したいので、コンボボックスに表示するためにフォームにハンバーガーの文字列表現を渡す必要があります。そうでない場合、UIはオブジェクトフィールドを掘り下げる必要があります。次に、ユーザーはコンボボックスからハンバーガーを選択し、コントローラーに送信します。ここで、コントローラーは、フォームで使用される文字列表現（おそらくID？）に基づいて、ハンバーガーを再度検索する必要があります。

それは信じられないほど非効率ではありませんか？既に選択したいオブジェクトがありました。オブジェクト全体をフォームに送信してから特定のオブジェクトを返した場合、フォームがそのオブジェクトへの参照をすでに返しているため、後でそれを見つける必要はありません。

さらに、私が間違っていて、実際にオブジェクト全体をフォームに送信する必要がある場合、UIをロジックから分離するにはどうすればよいですか？

^{まず第一に、あなたが提供した例は信じられないほど非効率的ではありません。わずかに非効率的です。その非効率性は知覚可能なレベルを下回っています。しかし、いずれにせよ、質問を続けましょう。}

私がそれを理解する方法は、UIとロジックの分離について話すとき、密接な結合の回避を意味しますます。

密結合とは、UIがロジックを認識（および呼び出し）し、ロジックがUIを認識（および呼び出し）する状況を指します。密結合を避けるために、結合を完全に廃止する必要はありません。（これは、それらの間のインターフェースを最小公分母文字列インターフェースに分解することで目指しているようです。）行う必要があるのは、疎結合を採用することだけです。

疎結合とは、AがBを知っているが、BはAを知らないことを意味します。言い換えると、関係する2つの関係者は、クライアントとサーバーの役割を果たします。

UIとロジックの場合、これを整理する最善の方法は、ロジックをサーバーとして、UIをクライアントとして見ることです。したがって、UIはロジック用に構築され、ロジックの知識を持ち、ロジックを呼び出しますが、ロジックはUIについて何も知らず、受け取ったリクエストに単純に応答します。（そしてこれらのリクエストはたまたまUIから来ますが、ロジックはそれを知りません。）

より現実的な言葉で言えば、ロジックのソースコードファイル内のどこにも、UIファイルを参照するinclude / import / usingステートメントはありませんが、UIのソースコードファイルはinclude / import / usingでいっぱいになります。ロジックファイルを参照するステートメント。

それで、あなたのケースに戻って、コンボボックスに入力するUIコードがハンバーガークラスを知っているという事実にまったく問題はありません。ハンバーガーのクラスがコンボボックスについて何かを知っている場合、問題が発生します。

ちなみに、この設計により、このようなシステムに期待できる別のことが可能になります。ロジックに必要なだけ多くの異なるUIをプラグインでき、全体が機能するはずです。

モデル、ビュー、コントローラーの各部分を分離する必要がありますが、コントローラーとビューの間でモデルオブジェクトを渡すことができない理由はありません（たとえば）。

したがって、あなたの場合、Hamburgerオブジェクトはモデルの一部になります。次に、コントローラーを使用して必要なHamburgersのリストを取得し、それらのオブジェクトをビュー（コンボボックス）に渡して表示します。ユーザーがどのハンバーガーを選択したら、Hamburgerオブジェクトを再びコントローラーに渡して処理することができます。

要点は、ハンバーガーの実際の表示とは別に、「fetch Hamburgers」ロジックと「process Hamburger」ロジックを単体でテストできることです。