HomeShopping - 01.회원가입 및 상품 등록.

많은 부분들을 건너뛰었지만, 같은 포멧을 페이지를 하나는 이클립스로 다이나믹 웹프로젝트로, 

하나는 STS로 Spring 프레임워크로 제작에 들어갔다.

일단, 프레임워크 없이 jsp로만 구성할때 문제가 Rest방식의 구현이었다.

Rest방식의 구현문제는 첫번째, 통신방법의 구현, 두번째 데이터 송-수신문제였다.

get방식은 URI에 값이 포함되어 전송되기에 문제는 없었으나 POST방식이 문제이다.

그리고 애노테이션을 사용하지 않고 구현하다보니 URI로 명령을 구분하는 작업을 위한 파싱작업에 들어가는 코드가 늘어난다.

데이터 수신문제는 request의 inputstream을 얻어와서 byte배열을 이용하여 String방식으로 가져온다.

그리고 기본적으로 JSON형태로 구현되어 있기때문에 Google의 Gson이라는 라이브러리를 이용하여 데이터를 파싱한다.

Spring도 마찬가지지만, 전송된 데이터가 하나의 객체로 전달되기 위해서는 "이름":"데이터" 형태가 지켜져야 한다.

(객채의 나열은 배열이다. 키와 값으로 구성된게 객체이고, 기본적으로 객체형태로 데이터가 꾸려져야한다.

배열을 전송해야되면, 키값을 두고 데이터영역에 배열을 위치시킨다.)

데이터와 대응되는 객체를 Gson으로 데이터 파싱할때 함께 전달한다.

데이터와 객체가 대응이 되는 상태라면 에러발생 없이 파싱된 값이 든 객체를 반환한다.

그리고 반대로도(객체->JSON) 가능하다.

결과를 주기위해서는 response객체의 writer를 얻어 사용한다. append 또는 write를 사용할 수 있는데 결정적인 차이는 아직 잘 모르겠다.

write가 text가 아닌 데이터를 byte배열단위로 전송할때 사용하는게 아닐까 하는 추측을 해본다.

기존 핸들러를 사용하는 서블릿 기반은 서블릿은 초반에 구현해두고 핸들러가 대부분의 역할들을 결정하게 된다.

물론, Rest구현도 비슷한 맥락이긴 하나(예를들어 Get방식이 여러개로 사용될때) 좀더 서블릿에서의 구현이 핵심이 된다.

Spring의 컨트롤러라고 봐야할것 같다.

메서드 이름은 

GET : doGet

POST : doPost

--------- 위 두개는 HttpServlet에 구현된 메서드다.

PUT : doPut

DELETE : doDelete

(PATCH : 아직 실험을 안해봤는데 이전 실험에서 보인 네이밍의 결과로 보면 아마 doPatch가 되지 않을까 한다.)

브라우저에서 전송 가능한 방식의 이름이면 네이밍이 가능한것 같고 위 네개는 통신이 되었다.

무튼, 서두에서도 말했지만, Spring과 동일한 동작방식을 구현하려면 URI파싱작업이 필요하고 그로인한 코드가 늘어난다.

그래서 서블릿에는 URI파싱 및, 전달된 데이터 최초가공 정도의 역할만 부여한다.

URI파싱을 통해 얻은 값과 전달된 데이터를 핸들러로 넘기면, 핸들러에서는 JSON파싱 및 객체로 변환작업을 한다.

이하 서비스 및 DAO는 동일한 역할이다.

이건 기술적인 기록이고, 

지금까지 해놓은것.

회원가입 - ID체크, Email체크기능(Rest방식처리)

로그인 기능 - jsp는 세션처리및 로그아웃까지, Spring은 로그인만.

물건 입고 데이터 저장 : 둘 다 해결. 처리결과가 아래에 바로 나타남.(Rest방식 처리)

** 다음으로 구현해야 하는 것들.

1. 회원관련 - 기본적인 게시판. 조회 및 리스트 출력

2. 운영진 관련 - 입력된 데이터 수정 페이지.