2

编辑
使事情复杂化似乎存在一个问题（正在播放 2.1 快照中处理），其中路由文件更改也可能触发冲压羊群效应，也就是说，重新编译控制器和依赖项。一旦解决了这个问题，并且集成了 Scala 2.10 + SBT 0.12.1 性能增强功能，那么我将更加清楚我在使用基于 trait 的 DAO 存储库时有多么自欺欺人......

ORIGINAL
我是说英语的人，能说很多很多，别担心，只是把你拉进....到可怕的慢 a$$ 编译区

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 组件：

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

对上述控制器进行更改似乎会触发依赖 DAO 提供程序的所有源的重新编译，在我的例子中是一堆控制器。最终的影响是，我经常看到近 3/4 的应用程序被重新编译，这很烦人。

现在，SBT 0.12.1 在编译速度方面有所提高，但就它重新编译的内容而言，我的 DAO 存储库实现显然无济于事。

所以，我的问题是，在这种情况下，我是否应该放弃特征并将 DaoRepo 对象直接暴露给控制器？播放器控制器将如下所示：

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

我是否正确假设对修改后的 Player 控制器进行更改不会触发重新编译我的应用程序的 3/4？我知道，直接使用 DaoRepo 对象进行测试是不可能的，但是等待也不是很有效率。

感谢您的反馈，如果你有它：帮助 SBT 重新编译必要的......

4

1 回答 1

2

您可以通过避免使用多个特征/类/对象定义填充单个文件来使 SBT 增量过程更智能。如果您有以下文件：

trait A { }
trait B extends Base { }

更改的定义Base将触发文件的重新编译，这反过来又会触发每个文件的重新编译，其中A或被B引用...

尝试将 DAO 和PlayerData类拆分为几个文件。

于 2012-10-16T14:03:11.303 回答