2

編集
複雑なことに、ルートファイルの変更が群れのスタンピング効果、つまりコントローラーと依存関係の再コンパイルをトリガーする可能性があるという問題 (Play 2.1 スナップショットで取り組んでいる) があるようです。それが解決され、Scala 2.10 + SBT 0.12.1 のパフォーマンス強化が統合されると、特性ベースの DAO リポジトリでどれだけ自分を撃っているのかがより明確になります...

オリジナル
私は英語を話す人で、多くの有能な人がいますが、心配する必要はありません。

trait DaoProviderContract {
  def team:   TeamContract
  def player: PlayerContract
}
object DaoRepo extends DaoProviderContract {
  import com.company.utils.{Connection, Driver}
  implicit lazy val db = Connection.getHandle(Driver.DEFAULT)

  val team    = new TeamDAO
  val player  = new PlayerDAO
}
trait DaoProvider[Contract <: com.company.dao.DAOContract[_]] {
  val daoRepo = DaoRepo
  val dao: Contract
}
trait TeamData extends DaoProvider[TeamContract] {
  val dao: TeamContract = daoRepo.team
}
trait PlayerData extends DaoProvider[PlayerContract] {
  val dao: PlayerContract = daoRepo.player
}

次に、コントローラーで、DAO コンポーネントを mixin します。

object Player extends Controller with PlayerData {
  ....
}

上記のコントローラーに変更を加えると、DAOプロバイダーに依存するすべてのソースの再コンパイルがトリガーされるようです。私の場合、これは一連のコントローラーです。正味の影響として、アプリケーションの 3/4 近くが再コンパイルされ、煩わしいことがよくあります。

現在、SBT 0.12.1 はコンパイル速度の点で改善されていますが、再コンパイルの点では、私の DAO リポジトリの実装は明らかに問題を解決していません。

それで、私の質問は、この場合、特性を廃棄して DaoRepo オブジェクトをコントローラーに直接公開するだけでよいのでしょうか? Player コントローラーは次のようになります。

import model.{DaoRepo => repo}
object Player extends Controller { // with PlayerData mixin gone
  def player(id: Int) = repo.player.get(id)
}

変更された Player コントローラーに変更を加えても、アプリケーションの 3/4 の再コンパイルがトリガーされないという仮定は正しいですか? DaoRepo オブジェクトを直接使用してテストすることは不可能であることはわかっていますが、それを待っていてもあまり生産的ではありません。

フィードバックをお寄せいただきありがとうございます。

4

1 に答える 1

2

単一のファイルに複数の特性/クラス/オブジェクト定義を詰め込まないようにすることで、SBT のインクリメンタル プロセスをよりスマートにすることができます。次のファイルがある場合：

trait A { }
trait B extends Base { }

の定義を変更するBaseと、ファイルの再コンパイルがトリガーされ、次に、またはが参照されているすべてのファイルの再コンパイルがトリガーされます...AB

DAO とPlayerDataクラスを複数のファイルに分割してみてください。

于 2012-10-16T14:03:11.303 に答える