为了让编译速度更快...少特点？

编辑
复杂的事情似乎有一个问题（在Play 2.1快照中正在处理），其中路由文件更改也可能触发令人生畏的畜群效应，也就是说，重新编译控制器和依赖关系。一旦得到解决，和Scala 2.10 + SBT 0.12.1性能增强集成，那么它会变得更加清晰，我多么拍摄自己与基于特征的DAO库脚...为了让编译速度更快...少特点？

ORIGINAL
我的英文讲很多很多有能力，不用担心，只要你拉在....到可怕的慢了$$汇编区

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) 
}

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

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

来源

2012-10-16 virtualeyes

可以使SBT渐进的过程更聪明，避免堆砌一个单独的文件与几个特质/类/对象定义。如果你有一个文件：

trait A { } 
trait B extends Base { }

改变的Base定义将触发文件的重新编译，这将反过来触发每文件，其中A或B被称为重新编译...

尝试在几个文件中拆分DAO和PlayerData类。

来源

2012-10-16 14:03:11 paradigmatic

+1，是的，我打破规则＃1：拆分成单独的源文件;然而，在各种scala库/应用程序中，我确实发现这个约定经常被破坏，可能是因为将单个源文件中的一些常见功能分组通常更容易。 – virtualeyes

应该注意，我可能会被Play 2框架中的一个“bug”困扰，有时路径文件可能是3/4应用程序重新编译中的罪魁祸首，显然正在2.1快照 – virtualeyes

@virtualeyes我don不认为它是一个“规则”。只是一个技巧来帮助增量编译器... – paradigmatic

为了让编译速度更快...少特点？

回答

相关问题