인내의숲
76
2021-10-13 13:57:00
9
935

비즈니스 로직이 쿼리에 전부 담겨있는 코드가 많이 흔한편인가요?


비즈니스 로직은 서비스에 담고 객체지향적인 코드를 짜야한다

강의나 책을 보면서 항상 강조하는 말인데


회사를 다니면서 소스를 보다보면 대부분 컨트롤러-서비스-dao는 그냥 데이터 전송하는 통로고


페이징이라던가 데이터 가공하는 부분은 쿼리에서 보통 조인걸고 서브쿼리쓰고 하면서 필요한 데이터를 쿼리로 다 만들고 쏴주는 식의 개발을 자주 하게 되는데


가끔 이게 맞나 싶더라구요


객체지향적이고 빠른 성능을 생각하며 개발한다면 쿼리는 단순하게 짜고 데이터 가공을 서비스단에서 자바로 가공하는 방식을 더 지향하는게 맞나요??


회사에서는 다들 쿼리로 해결하는 분위기가 강해서 오키에 물어보게 됐습니다

0
  • 댓글 9

  • 20170923
    2k
    2021-10-13 14:05:07

    기능 별로 다를 수도 있겠지만 DB에서 가져와서 서비스 단에서 가공하는 게 더 효율적이라고 알고 있습니다.

  • fender
    23k
    2021-10-13 14:06:57

    제가 볼 땐 그냥 SQL 잘하는 개발자는 많은데 객체지향에 익숙한 개발자는 적기 때문이지 특별히 다른 이유는 없다고 생각합니다.

  • defult
    13k
    2021-10-13 14:09:48 작성 2021-10-13 14:12:00 수정됨

    일로써 하는 경우는 공학적인 효율보다는 상업성적인 효율이 더 중시되는 경우가 흔합니다.


    실제 많은 회사의 개발기반은 요즘 이게 효율좋다 나오는것보다 더 오래전의 기반으로 개발된 제품도 많고

    그 기반이 오래되고 단순히 개발 기반의 공식 서포트적인 접근으로 언어만 최신으로 교체하고 개발내용적인 면은 과거의 구성을 최대한 무너트리지않는 방식이 “기업 입장에서는” 선호되는 경우가많습니다.

    기존에 돌아가던 기법, 인력을 기반으로 구축하는것은 당장의 개발비만 회사가 고려하면 되지만

    그것들을 효율이라는 미명하게 근간을 새로 구축하면 회사입장에서는 리스크 비용은 상상을 초월합니다.

    그리고 그걸 최종 판단할 결정권자는 개발자가 아닌 개발 효율을 이해못할 개발과 무관한 경영자들이라는것도 큽니다.


    일로써 하는경우는 그런 부분은 자신이 그런 효율성부터 고려하고 책임지는게 가능한 입장이 아닌이상 상업성을 위한 호환성 안정성을 위해서기존의 방식을 최대한 남기는 개발을 한다고 생각하고 접근하면 됩니다.


    혹은 개인적인 공부가 아닌 업무로써까지 최신의 기법을 고려하고싶으면 코어영역부터 새롭게 구축하는 개발을 찾으셔야합니다

  • 날라리개발자
    721
    2021-10-13 14:40:37

    쿼리만 보고 문제가 뭔지 파악하려는 현업 관리자들이 많습니다

  • hk2005
    292
    2021-10-13 14:44:23 작성 2021-10-13 15:23:50 수정됨

    조회성 화면의 경우 유지보수 측면에서 그런 거 같습니다.

    1. 여러가지의 데이터를 소스에서 조합하면 쿼리, 소스, 화면을 모두 고쳐야 하는데, 쿼리로 해결하는 경우 쿼리만 수정하면 되는 경우가 있습니다.

    2. 소스를 컴파일해서 올릴 경우 서버를 재기동해야 하는데 xml 파일만 올릴 경우 세팅에 따라 서버 재기동을 안 해도 됩니다. (요즘엔 보안 때문에 불가능한 곳이 많겠지만.. 예전 프로젝트에서 대부분의 처리를 프로시저로 하는 곳도 보았습니다.)

    덧1. 요즘 추세적으로 예전처럼 운영 반영을 직접적으로 하는 걸 금지하고 있고, 보안과 소스 관리 측면에서 나눠서 개발하는 게 바람직하기 때문에 점점 바뀔 거라 생각합니다.

    덧2. 현재 일하는 곳의 소스처럼 짜는 건 앞으로 지양해야겠지만 쿼리랑 db는 잘 알아두면 어디 가서도 유용합니다!

  • 만년코더
    9k
    2021-10-13 15:10:23 작성 2021-10-13 15:11:08 수정됨

    hk2005님께서 말씀하신 부분이 젤 큽니다.


    그냥 새로 만들기는 급해서 그런거죠.

    모듈을 추가하거나 변경하는거 보다 

    XML만 수정하면 되면 그게더 편하기 때문이죠.

    편하다고 옳은 방향은 아니긴한데...

    뭐 SI SM이라는게 현업 측에서 충분한 기간과 비용을 보장하지 않는 경우가 많아서

    그냥 임시방편으로 빨리 고치다보니 그게 굳어진 거죠.


    그러다 차세대하면 분석해서 모듈 새로만들고 정리하고 하다가도 

    시간 좀 지나면 네이티브 쿼리가 떡칠되고 그렇습니다.

  • 장독깨기
    3k
    2021-10-13 16:36:50

    보통 대부분 서비스 시스템들은

    비지니스를 분석하고 그에 맞게 데이터베이스를 설계합니다.

    즉, 비지니스 로직 대부분이 데이터베이스에 녹아져 있다라고 볼 수 있습니다.

    그러니, 객체지향적으로 하고 말거도 없이 데이타베이스 인아웃만 잘 처리하면 대부분이 해결이 됩니다.

    성능적인 측면에서도 한번의 쿼리로 해결하는게 훨씬 이득입니다.

    혹시나 이걸 ORM 으로 한다해서 객체지향적이라고 말 할 수 없으며,

    성능적인 측면에서도 이득이 전혀 없습니다.

    그러나, 종종 데이터베이스 인아웃과 관련 없는 부분에서

    객체지향적으로 프로그래밍을 해야 할 경우들이 생깁니다.

    이때 이걸 잘 처리하면 잘 한다는 소리 듣습니다. :)

  • InTheFlow
    209
    2021-10-13 17:23:04 작성 2021-10-13 17:23:40 수정됨

    제가 SI 책을 본 것이 있는데 그것을 토대로 말씀 드리겠습니다.

    SI는 품질은 전혀 고려하지 않습니다.

    오로지 일정 내에 돌아가게만 만들면 됩니다.

    이에 개발자는 유지보수가 편한 코드가 아니라 최대한 빠르게 끝낼 수 있는 코딩을 하게 됩니다.

    고객의 요구사항이 매번 바뀌는 상황에서 어떻게 하면 빠르게 개발할 수 있을 것인가?

    그것은 바로 JAVA 단은 전혀 수정하지 않아도 되게 비즈니스 로직을 모두 SQL에 담는 것입니다.

    이러면 다른 파일은 건드리지 않고 mapper 파일만 변경하면 됩니다. 서버 재기동도 필요 없죠.

    심지어 VO도 만들지 않고, 모든 것을 MAP으로 담아서 MAP과 LIST로 모든 걸 끝낸다고도 하더군요.


    또한 객체지향적 설계가 잘 되지 않는 이유는 JPA 관련 책의 앞부분을 읽으며 알게 됐습니다.

    자바는 객체 지향 모델인데, DB 는 데이터 중심 모델이지 않습니까?

    이 사이를 매핑하는 것은 개발자의 능력이겠죠.

    그런데 앞서 말씀드린대로 기한이 짧고, 요구사항이 마구 변하는 상황에서 과연 이 매핑을 제대로 할 수 있을까요? SQL 쿼리만 짜기도 바쁜 일정 속에서요?

    그래서 객체지향 따윈 집어치우고 데이터 중심 개발을 하게 돼 있는 것입니다.

    정 객체지향적 설계와 개발을 하려면 JPA,Hibernate를 도입해야 된다고 봅니다.

    그런데 SI에서 그런 프로젝트는 거의 없겠죠. 


  • 쿡쿠
    1k
    2021-10-13 20:26:38
    페이징은 쿼리로 하는게 맞고요. 데이터가공은 서비스나 매퍼에서 하는게 맞지 않을가요.. 
  • 로그인을 하시면 댓글을 등록할 수 있습니다.