Spring には、このコントローラーがアクセスできるメソッドを提供するサービス インターフェイスであるコントローラーがあります。コントローラーは、サービスのさまざまな実装メソッドを呼び出します。
scala で同じ「設計の分離」を実現するには、これが正しい実装です。scala コントローラーを定義し、サービス インターフェイスとして機能する scala トレイトを定義します。この特性を拡張し、サービスの実装を提供する新しいクラスを定義します。次に、コントローラはこの新しいクラスを開始し、サービス メソッドのさまざまなメソッド実装を呼び出します。
これは良い設計ですか、それともSpring MVCが実際にどのように使用されていますか?
「優れた設計」はかなり主観的なものであり、「優れた設計」の意味はプログラマごとに時間とともに変化します。ほとんどの人がベスト プラクティスと見なすものはいくつかありますが、ベスト プラクティスでさえ矛盾があります。私の個人的な意見では、プログラマーはこれらのベスト プラクティスを学び続け、さらに重要なこととして、その状況に最適な形になるまでコードを作成し続ける必要があります。ただし、プログラマーが学習を続けるにつれて、「最適な」形状であるポイントは変化し続けます。
私は状況を知らないので、あなたの場合の「良いデザイン」とは何かを教えることはできません。その上、私はあなたではないので、私の「良いデザイン」はあなたに最適ではありません. いくつかの質問の助けを借りて、自分で見つけることをお勧めします。
他の人がコメントしているように、「良いデザイン」は他の要因に依存する柔軟な概念です。その議論には追加しませんが、代わりに私たちのアプローチの概要を提供します.
Spring MVC の代わりに Jersey を選択しましたが、従来の Java & Spring webapp から始めました。その後、Scala で書き直しましたが、うまくいきました。私たちは意図的に Java に似たスタイルの Scala を維持しました。
次に、Spring をその XML と推移的な依存関係全体と共に削除することにしました。これは簡単でした。なぜなら、コンストラクターによって注入された依存関係 (もちろんすべて TDD) を持つすべてのクラスである一連のサービスとコントローラーが既にあったからです。サービスとコントローラーをインスタンス化する新しい Bootstrap クラスを作成し、各コンストラクターのパラメーター リストに必要な具象クラスを提供するだけで済みました。便利なことに、Bootstrap クラスは基本的に、元の Spring ワイヤリングを (非常に単純な) Scala に音訳したものです。Bootstrap クラスは、アプリの起動時に web.xml から開始されます。(このアプローチは、Pico Container を使用したことがある人なら誰でも知っているでしょう。)
私たちの場合、サービス層で特性をあまり使用する必要はありませんでした。TDD によって駆動される具体的なクラスのクリーンな設計で十分でした。しかし、私たちのアプローチは、必要に応じて、サービスのプラグ可能な抽象化でもうまく機能します。
これで、web.xml 以外の XML を持たず、純粋に Scala で作成された Web アプリケーションが完成しました。これにより、ナビゲートと変更が容易になり、外部依存関係がはるかに少なくなります。これは私たちにとって非常にうまくいきました。