Anorm Parsers에 대한 더 나은 코드 레이아웃

SQL 테이블에서 데이터를 검색하기 위해 Scala, Anorm 및 Play2 Framework를 사용하고 있습니다. 이 엉망 매개 변수 순서/길이 매우 쉽게 때문에,Anorm Parsers에 대한 더 나은 코드 레이아웃

val emailViewRecordParser: RowParser[EmailViewRecord] = { 
    str("sfname") ~ 
    str("slname") ~ 
    str("practice_name") ~ 
    str("email") ~ 
    str("phone_area_code") map { 
    case 
     subscriberFirstName ~ 
     subscriberLastName ~ 
     practiceName ~ 
     subscriberEmail ~ 
     phoneAreaCode 
     deviceAddress => 
     EmailViewRecord(
     subscriberFirstName, 
     subscriberLastName, 
     practiceName, 
     subscriberEmail, 
     phoneAreaCode 
    ) 
    } 
}

이 관리하기 어려운 : 많은 장소에서이 같은 코드가 있습니다. 이상적으로 우리의 라인을 따라 뭔가를 쓸 수있을 것입니다 :

그 라인을 따라 레이아웃을 달성하는 좋은 기능 방법은 무엇

val emailViewRecordParser: RowParser[EmailViewRecord] = { 
EmailViewRecord(
    str("sfname") map { subscriberFirstName } subscriberFirstName, 
    str("slname") map { subscriberLastName } subscriberLastName, 
    str("practice_name") map { practiceName } practiceName, 
    str("email") map { subscriberEmail } subscriberEmail, 
    str("phone_area_code") map { phoneAreaCode } phoneAreaCode 
) 
}

? 또한 처음에는 'str'함수가 int, date 등일 수 있으므로 첫 번째 함수는 모든 라인에 고유해야합니다.

출처

2014-10-09 Bill Frasure

라인 파서의 문제점은 전체 라인에서 사용하기위한 것입니다 . 나는 당신의 문제가 그것과 관련이 없다고 제안하지만, 반복적으로 모든 것을 혼란스럽게 만드는 거대한 이름을 반복적으로 주면서 더 이상 논리에주의를 기울일 수는 없다. 다음을보십시오 :

str("sfname") ~ str("slname") ~ str("practice_name") ~ 
str("email") ~ str("phone_area_code") map { 
    case a~b~c~d~e => EmailViewRecord(a,b,c,d,e) 
}

잘못 이해하는 것이 더 어렵습니다. 더 많은 도구를 포함, 다른 가능한 해결책이 있습니다

val parser = 
    str("sfname") ~   // Subscriber first name 
    ... 
    str("phone_area_code") // You'll never guess that this is the area code. 

parser map { case a~b~c~d~e => EmailViewRecord(a,b,c,d,e) }

,하지만 난 그것을 노력의 가치 귀하의 경우 확실하지 않다 : 당신이이 부적절하게 설명되어 느끼면과 같이 파서 라인에 주석을 추가 할 수 있습니다.

출처

2014-10-09 06:14:30

우리는 15 개 이상의 열이있는 테이블이 많기 때문에 다음과 같은 긴 행이 생깁니다. case a ~ b ~ c ~ d ~ e ~ f ~ g ~ h ~ i ~ j ~ k ~ l ~ m ~ n => EmailViewRecord (a, b, c, d, e, f, g, h, i, j, k, l, m, n) 을 따라야하기 때문에 읽기가 어렵습니다. 1 개의 수직리스트를 2 개의 수평리스트로 변환하면, 각각 에 붙습니다. col_a -> a -> a \ n col_b -> b -> b \ n 등등을 사용하는 접근법은 각 변수의 변환을 쉽게 추적 할 수 있기 때문에 더 쉽게 유지 관리 할 수 있습니다. –

@swoogles - 포인트는 실수하지 않을 것입니다. 문서화와 변환의 모든 것은 수직 목록에서 발생합니다. 나머지 요소는 같은 수의 요소 만 있으면됩니다. –

@swoogles 15 개 이상의 열이있는 테이블이 여러 개있는 경우 데이터를 정규화하거나 파티셔닝하는 것이 좋습니다. 그런 다음 하나의 파서로 여러 구문을 작성할 수 있습니다. –

Anorm Parsers에 대한 더 나은 코드 레이아웃

답변

관련 문제