我分别使用Play-Slick版本2.5.x和3.1.x.我使用Slick的代码生成器并从现有数据库生成Slick模型。实际上,我很羞于承认我是数据库设计驱动而不是类设计驱动。
这是初始设置:
generated.Tables._
这些是我临时称为“Pluggable Service”的模式背后的力量,因为它允许将服务层功能插入到模型中:
UserService
UserRow
应符合业务层接口,例如Deadbolt-2的主题但不直接实现它。为了能够实现它,需要“太多”,例如UserRow
模型类型,UserDao
以及可能的某些业务背景。UserService
方法自然适用于模型UserRow
实例,例如loggedUser.roles
或loggedUser.changePassword
因此我有:
generated.Tables.scala
光滑的模型类:
case class UserRow(id: Long, username: String, firstName: String,
lastName : String, ...) extends EntityAutoInc[Long, UserRow]
dao.UserDao.scala
特定于用户模型的Dao扩展和自定义:
@Singleton
class UserDao @Inject()(protected val dbConfigProvider: DatabaseConfigProvider)
extends GenericDaoAutoIncImpl[User, UserRow, Long] (dbConfigProvider, User) {
//------------------------------------------------------------------------
def roles(user: UserRow) : Future[Seq[Role]] = {
val action = (for {
role <- SecurityRole
userRole <- UserSecurityRole if role.id === userRole.securityRoleId
user <- User if userRole.userId === user.id
} yield role).result
db.run(action)
}
}
services.UserService.scala
将所有用户操作展示到Play应用程序其余部分的服务:
@Singleton
class UserService @Inject()(auth : PlayAuthenticate, userDao: UserDao) {
// implicitly executes a DBIO and waits indefinitely for
// the Future to complete
import utils.DbExecutionUtils._
//------------------------------------------------------------------------
// Deadbolt-2 Subject implementation expects a List[Role] type
def roles(user: UserRow) : List[Role] = {
val roles = userDao.roles(user)
roles.toList
}
}
services.PluggableUserService.scala
最后是实际的“可插入”模式,它将服务实现动态地附加到模型类型:
trait PluggableUserService extends be.objectify.deadbolt.scala.models.Subject {
override def roles: List[Role]
}
object PluggableUserService {
implicit class toPluggable(user: UserRow)(implicit userService: UserService)
extends PluggableUserService {
//------------------------------------------------------------------------
override def roles: List[Role] = {
userService.roles(user)
}
}
最后可以在控制器中做到:
@Singleton
class Application @Inject() (implicit
val messagesApi: MessagesApi,
session: Session,
deadbolt: DeadboltActions,
userService: UserService) extends Controller with I18nSupport {
import services.PluggableUserService._
def index = deadbolt.WithAuthRequest()() { implicit request =>
Future {
val user: UserRow = userService.findUserInSession(session)
// auto-magically plugs the service to the model
val roles = user.roles
// ...
Ok(views.html.index)
}
}
是否有任何Scala方法可以帮助您不必在Pluggable Service对象中编写样板代码?可插拔服务名称有意义吗?
答案 0 :(得分:1)
常见变体之一可能是控制器的父特征,其中包含以下内容:
def MyAction[A](bodyParser: BodyParser[A] = parse.anyContent)
(block: (UserWithRoles) => (AuthenticatedRequest[A]) => Future[Result]): Action[A] = {
deadbolt.WithAuthRequest()(bodyParser) { request =>
val user: UserRow = userService.findUserInSession(session)
// this may be as you had it originally
// but I don't see a reason not to
// simply pull it explicitly from db or
// to have it in the session together with roles in the first place (as below UserWithRoles class)
val roles = user.roles
block(UserWithRoles(user, roles))(request)
}
这里房间里的大象是你如何得到userService
实例。那么你需要在你的控制器构造函数中明确要求它(与你对DeadboltActions
的方式相同)。或者,您可以将DeadboltActions
,UserService
和其他内容捆绑到一个类中(例如ControllerContext
?)并将此单个实例作为一个构造函数参数注入(但这可能是另一个讨论。 ..)。
之后您的控制器代码将是这样的:
def index = MyAction() { implicit user => implicit request =>
Future {
// ...
Ok(views.html.index)
}
}
user
和request
都是隐含的,这有助于传入应用程序的内部部分(通常是这种情况 - 您带来user
对象来执行某些业务逻辑)。
它本身并没有摆脱你的PluggableUserService
(逻辑仍在那里),但它可以帮助你更轻松地在你的控制器中重复使用相同的逻辑(根据我的经验,你需要有在任何实际应用中,User
和Roles
通常都是{。}}。
PluggableUserService
中使用样板文件,或者你想避免在每个控制器中使用PluggableUserService
来分散这种转换(恕我直言第二选项是要避免的)?