6

私はしばらくscalaを学び始め、今はケーキのパターンを見ています。ここから例を取得しました

trait UserRepositoryComponent {
  def userLocator: UserLocator

  trait UserLocator {
    def findAll: List[User]
  }
}

trait UserRepositoryJPAComponent extends UserRepositoryComponent {
  val em: EntityManager

  def userLocator = new UserLocatorJPA(em)

  class UserLocatorJPA(val em: EntityManager) extends UserLocator {
    def findAll = {
      println("Executing a JPA query")
      List(new User, new User)
    }
  }
}

trait UserServiceComponent {
  def userService: UserService

  trait UserService {
    def findAll: List[User]
  }
}

trait DefaultUserServiceComponent extends UserServiceComponent {
  this: UserRepositoryComponent =>

  def userService = new DefaultUserService

  class DefaultUserService extends UserService {
    def findAll = userLocator.findAll
  }
}

私には、JPA リポジトリをサービスに注入するには定型コードが多すぎるように見えます。

ただし、このコードは、はるかに少ない行数で同じことを行います

trait UserRepository {
  def findAll
}

trait JPAUserRepository extends UserRepository {
  val em: EntityManager
  def findAll = {
    em.createQuery
    println("find using JPA")
  }
}

trait MyService {
  def findAll
}

trait MyDefaultService extends MyService {
  this: UserRepository=>
}

両方のシナリオをインスタンス化します。

val t1 = new DefaultUserServiceComponent with UserRepositoryJPAComponent {
  val em = new EntityManager()
}
t1.userService.findAll


val t2 = new MyDefaultService with JPAUserRepository {
  val em = new EntityManager
}

t2.findAll

2 番目のシナリオでは、はるかに少ないコードを使用し、DI を使用します。ケーキパターンがもたらす追加の利点を理解するのを手伝ってもらえますか.

4

3 に答える 3

2

私が理解しているように、大きな違いはありません。実はケーキ柄はIoC. これは、個別のフレームワークを使用せずに、scala コードのみを使用してIoCandを実装するというアイデアにすぎません。より多くの機能が必要でない限り、おそらく別のコンテナーよりも優先する必要があります。DIDIDI

また、あなたの例は両方ともケーキのパターンのように見えます。少なくとも私はそう理解しています。しかし、Martin は彼の本の中でそれを「ケーキ パターン」とは呼んでいませんでした。私の理解では、ケーキのパターンは、さまざまな特性を組み合わせて達成するアイデアですDI

DIマーティンは彼の著書で、 Spring のようなコンテナーを scala で使用しても問題ないと具体的に述べていると思いますが、残念ながらこの場所を見つけることができません。

アップデート

見つけました: http://www.artima.com/pins1ed/modular-programming-using-objects.htmlの最後のサブパラグラフを参照してください27.1 The problem。しかし、私が言ったように、彼はここで「ケーキ」について話しているのではありませんが、アイデアはあなたが提供した記事と同じように見えます

更新 2

回答を読み直して、質問に完全に回答していないため、改善する必要があることを理解しました。

「ケーキ柄」の方がシンプルなのでおすすめです。Spring を使用する場合、XML であろうと注釈であろうと、構成を維持する必要があります。また、クラスに対していくつかの要件がある場合があります (私は Spring を使用したことがないので、あるかどうかはわかりません)。春全体をあなたと一緒に。Cake パターンを使用すると、単純なコードを記述できます (2 番目の例は単純です。同意する必要があります)。scala の優れている点は、それを使用して多くのことを行うことができ、少数のフレームワークしか使用できないことです (java と比較すると、通常はより多くの外部ライブラリを使用します)。

プロキシなどのより高度な機能が必要になった場合は、Spring に切り替えるか、引き続き Scala を使用して言語自体の問題を解決できます。うまくいけば、scala は非常に強力で、複雑なケースでもカバーできるはずです。

あなたが提供した 2 つのコードの違いは単なる抽象化です。最初のコードには、リポジトリとサービスで定義された操作に対するもう 1 つの抽象化があり、これらはパターンの一部ではありません。これは必須ではないと思いますが、著者はこのように表示することにしました。

于 2015-10-12T16:25:42.063 に答える