使用Play框架和具有超过22个参数的案例类 [英] Using Play Framework and case class with greater than 22 parameters

查看:158
本文介绍了使用Play框架和具有超过22个参数的案例类的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我还看到了其他一些与臭名昭著的"22字段/参数"问题有关的问题,这是Scala V< 5的固有错误(功能?). 2.11.请参见此处博客帖子,它似乎case class中的22个参数限制已固定;至少在涉及语言的地方.

I have seen some of the other issues involving the infamous "22 fields/parameters" issue that is an inherent bug (feature?) of Scala V < 2.11. See here and here. However, as per this blog post, it appears that the 22 parameter limit in case class has been fixed; at least where the language is concerned.

我有一个case class,我想加载任意数量(读取:> 22)的值,以后使用Play库将这些值读入JSON对象.

I have a case class that I want to load an arbitrary (Read: > 22) number of values into which will later be read into a JSON object using the Play library.

它看起来像这样:

object L {
  import play.api.libs.json.Reads. _
  import play.api.libs.functional.syntax._

  implicit val responseRead: Reads[L] = (
    MyField1.jsPath.Read[MyField1.t] and 
    MyField2.jsPath.Read[MyField2.t] and
    ...
    MyField35.jsPath.Read[MyField35.t]
  ) (L.apply _)
}

case class L(myField1: MyField1.t, myField2: MyField2.t, ... myField35: MyField35.t)

问题在于,在编译时,Scala抱怨case class中有22个以上的参数. (特别是:在对象定义的最后一行,当编译器尝试构建时,我得到:实现将函数限制为22个参数".)我目前正在使用Scala v2.11.6,因此我认为这不是语言问题.这让我认为Play库尚未更新Read的实现.

The issue is that on compile, Scala complains that there are more than 22 parameters in the case class. (Specifically: on the last line of the object definition, when the compiler attempts to build, I get: "implementation restricts functions to 22 parameters".) I'm currently using Scala v2.11.6, so I think it's not a language issue. That makes me think that the Play library hasn't updated their implementation of Read.

如果是这种情况,那么我猜最好的选择是将相关字段分组为元组,然后将元组通过JSON API传递进来?

If that's the case, then I guess the best bet is to group related fields into Tuples and pass the Tuples in through the JSON API?

推荐答案

所以,这个问题的答案实际上是两部分:

So the answer to this question is actually two parts:

我将其称为解决方法",因为虽然它起作用",但通常可以解决症状而不是问题.

I'll call this the "workaround" because while it does "work" it usually addresses the symptom and not the problem.

我的解决方案是使用shapeless提供任意长度的通用异构列表.该解决方案已经被广泛讨论,并可以在其他地方获得.参见例如(1)[SO Post] 博客帖子; (3)还有另一篇博客文章.

My solution was to use shapeless to provide generic heterogeneous lists of arbitrary length. This solution is already widely discussed and available elsewhere. See, e.g., (1) [SO Post] How to get around the Scala case class limit of 22 fields?; (2) Blog post; (3) Yet another blog post.

就像@ jeffrey-chung提到的那样,是要重组模型以应对此限制.正如行业中许多人所指出的那样,拥有一个带有30个以上参数的函数很可能表明您的函数执行了太多操作,或者应该重构该函数以吸收较少数量的参数.参见例如(1)规则30 –什么时候方法,类或子系统太大?; (2) Databrick的样式指南.

As @jeffrey-chung mentions is to restructure the model to deal with this limit. As many in the industry have noted, having a function with more than 30 arguments is likely a sign that your function is doing too much or that the function should be refactored to ingest a smaller number of arguments. See, e.g., (1) Rule of 30 – When is a method, class or subsystem too big?; (2) Databrick's style guide.

这篇关于使用Play框架和具有超过22个参数的案例类的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆