ABOUT ME

-

Today
-
Yesterday
-
Total
-
  • ParameterParser & post 통신
    JavaScript/JSP 2019. 2. 28. 16:49
    반응형

    ParameterParser getStringParameter vs HttpServletReqeust  getParameter()


     기존의 레거시 프로젝트가 jsp 안에 html+js+java 가 다 있는 형태이다. 스프링하면서 mvc 에 병적으로 집착하면서 구조를 어떻게든 깔금하게 분리해서 관리하려는 나로써는 정말 세상 최악의 구조이다. 

     그래도 담당자가 되었기에 유지보수는 하고 있다. 이전 개발자가 ParameterParser 를 사용하여 파리미터 전달 받은 값을 사용하도록 개발을 해놓은것같다. ParameterParser는 명확하게 값이 없을 경우 자신이 정한 디폴트 값을 넣어줄수있는 편리함때문에 사용하는것에 대해선 아주 괜찮은거 같았다. 


    String strGameIndex = request.getParameter("gameindex");
    if( strGameIndex == null ) strGameIndex = "0";
    int gameindex= Integer.parseInt(strGameIndex);
    ParameterParser pp = new ParameterParser(request);
    int gameindex= pp.getIntParameter("gameindex", 0);

      두 경우를 보면 결론은 같으나 ParameterParser 사용할경우가 확실히 소스상의 간결함은 나은것 같다. 이경우 만일 요청이 post 로 처리해야한다고 할때, 둘다 동일하게 동작하는것인가가 궁금하다. 결론부터 말하면 ParameterParser를 사용해서 post 데이터를 추출할경우 데이터가 뽑히지 않는다. 

     내부로직을 확인해 보니 HttpServletReqeust 가 아닌 ServletRequest 를 사용하고 있다. ServletRequest 은 클라이언트자체에 대한 정보를 추출이 가능하고 보내온 정보들을 확인이 가능하다. 그렇기 때문에 우리가 일반적으로 http 프로토콜을 활용한 정보 추출은 HttpServletReqeust 으로 확장해서 사용이 가능하다.  제공하는 메서드의 종류들을 보면  매개변수들의 Enum 객체들이나 입력스트림 , 매개변수가 가진 값들 그리고 기타 클라이언트 접속 정보들을 가져올수 있다. ServletRequest 을 사용해도 충분히 HttpServletReqeust 로 선언된 객체와 동일한 기능을 수행할수 있다고 판단 했다. 

     그럼 왜 post 데이터가 추출이 안되는지 다른부분을 더확인해봤다. 단순하게 HttpServletReqeust  로 선언된 request 객체에서 request.getParameter() 를 사용하면 어떨까 해봤다. request 객체에 있는 getParameter 메서드를 사용할경우 get이든 post 든 알아서 뽑혀 나왔다. 결국은 getStringParameter 를 사용할때 내부적으로 가져오는값을 기존에 getParameter가 아닌 getParameterValues 를 사용하는 ParameterParser가 문제가 post 방식의 통신에선 적합한 방법이 아닌걸로 판단된다. 


     소스의 간결함이 유지보수나 여러가지측면에서 좋다라고 생각은 한다. 하지만 가끔은 for(String s : data ) 보단 for(int i=0 ; i <size  ;i++) 같은 고전 감성으로 하는것도 좋지 않을까 싶다. 

     지금 이 문제를 발견한 프로젝트는 솔직히 소스가 길지도 않고 보는데 어렵지도 않다. 그렇기 떄문에 굳이 저런걸 쓸필요까진 없었을거 같다. ParameterParser 를 안써본사람이 있다면 ParameterParser 가 뭔지 사용법은 어떤건지 찾는 노력이 필요할텐데 운영여건상 잘 맞지 않을수 있는 여지가 있다면 굳이 라이브러리를 남발하여 사용 하지 않는게 좋을거 같기도 하다.  

     ParameterParser  기능은 cos.jar 란 라이브러리 안에 있고 내 기억이 맞다면 보통 multipart 로 파일을 업로드하거나 할떄 필요해서 추가를 많이 하는 라이브러리라고 알고있다. 물론안에 여러기능들이 종합적으로 묶여 있는걸로 알고있다. 

     순전히 개인적인 취향이지만 내소스를 보고 누군가 감동받을 정도의 고퀄리티의 소스를 제작 못할바엔 대학생이 봐도 쉽게 짜보자라는 주의라서 소스가 좀 길어지더라도 난 두줄짜리 소스보단 세줄짜리 소스를 쓸거 같다. 

     무조건 그렇게 하겠다는건 아니지만 SI 나 솔루션 회사들 게임회사들을 다니면서 가장 일할떄 힘든건 남이 자기만 알수있게 만든 소스를 파악하는것 같다. 

     적어도 난 남에 피해주지 않는 개발자가 되고 싶다. 생각해보면 남들이 잘볼수있는 소스란걸 짜기 참힘든거 같지만 노력하고 습관이 되면 좋지 않을까 싶다. 성능에 영향이 없는한 최대한 보기쉬운 코드를 만들어야겠다. 


    남을 위해서 그리고 나를 위해서 


    반응형
Designed by Tistory.