설계를 희한하게 하는 바람에 꼬인 문제같긴 합니다만. 여쭙습니다.
상황은 mybatis select 실행될 시에 return object 의 getter 가 호출되면서인데요. getter 안에 다른 property 에 의존중인 코드가 삽입되어 있어서, 만약 다른 mybatis select 구문에 해당 property 가 없다면 exception 이 발생하게 됩니다.
이를 피하고자 문제를 가진 getter 내에 reflection 의 주체가 되는 객체를 찾아 그 객체가 mybatis 라던가 하는 경우엔 다른 예외의 로직을 타게 하고 싶어서 입니다.
즉, mybatis 에서 getter 를 이용한 reflection 이 진행중이라면 A 로직을 타게 하고. jsonseriaizer 같은 다른 객체에서 getter 를 이용한 reflection 이 진행중이라면 B 로직을 타게 하고 싶습니다.
현재는 문제의 property 에 대해선 jsonignore 등을 적용하고, jsonproperty 를 다른 naming 의 메소드를 이용하게끔 해놓았습니다.
도메인과 view 와 엮여있는 모델이라 생긴 문제같긴 합니다만... 딱히 다른 해결방안이 생각나질 않네여.
지금은 원 제목과 같은 질문의 방안과 당장 적용해놓은 문제외엔 딱히 방법이 생각나질 않네요.
6개의 의견 from SLiPP
음 뭔가 상당히 좋지 않은 디자인인듯 하다.
뭐 사정이 있을거라고 생각 하고
이런걸 원하는 거냐?
역시나 좋지 않은 방법이지만 위에 exception이 발생한다고 했으니 exception에서 stacktrace를 찾아봐도 될듯 하고.
간단히는 그냥 위에 exception날 때 다른 로직 타게 하던지...
그러나 전부다 엄청 위험한 코드일듯 하다.
하지만 가급적이면 기존 코드를 리펙토링 하길 바란다.
@jhindhal.jhang 아... stacktrace 를 봐야하는 방법밖에 없나보네여 ㅠㅠㅠㅠ 질문 작성하면서도 그거외에 생각나질 않았는데... 도메인이랑 뷰가 같은 모델을 쓰다보니 생기는 문제인데, 가장 핵심 모델이라 이거 리팩토링하려면 정말 후덜덜해서.... 일단 임시방편으로 작업해놓은 그 코드를 계속 유지해야하나 싶네요.
가장 핵심 모델이라면 더더욱 빨리 리펙토링 해야할듯 한데... 뭐 말이 쉽긴하지만..
resultMap의 컬럼을 추가해줘야 하는 거 아닌가.
상황에 따라 다르게 하고 싶으면 resultmap하고 select 를 더 만들고.. DB매핑을 수정하고
JAVA reflection이 필요한 문제인지 의문이 든다. https://www.artima.com/underthehood/invocationP.html
@jin윤석진 그럼... query 에 logic 이 들어가기 시작해서요... 그건 피하려고 ㅠㅠ domain model 에 있는 value와 view model 에 있는 value 를 한 모델에 담고 쓰다보니까 생긴 문제라서요. 같은 네이밍의 getter를 domain, view 같이 쓰는데 domain 과 view 각각 다른 로직을 타야해서리... 글구 형... 제가 아직 초보라서 링크를 잘 이해못하겠어요 ㅋㅋ
의견을 남기기 위해서는 SLiPP 계정이 필요합니다.
안심하세요! 회원가입/로그인 후에도 작성하시던 내용은 안전하게 보존됩니다.
SLiPP 계정으로 로그인하세요.
또는, SNS 계정으로 로그인하세요.