##특징

1. 소형 프로젝트를 위한 JAVA 경량 프레임웍입니다. API server를 만드는 데 적합합니다.
2. 클래스, 객체 생성을 최소화하고, 1 API = 1 Method 원칙에 입각해 만들었습니다.
3. DB는 JSON format의 데이터를 반환합니다. (DatabaseManager에서 리턴 타입과 메세지 형식을 수정할 수 있습니다.)
4. 클래스 생성을 최대한 자제하고 4개의 클래스와 단순한 로직만으로 작성하였습니다.
5. maven 사용법을 알지 못해도 서버 개발을 할 수 있도록 jar파일을 포함하여 커밋하였습니다.
6. MethodHandler 클래스에 예시 코드를 삽입해 두었습니다. //core method 아래의 메소드는 삭제하고 작성하시면 됩니다.

##사용방법

1. https://github.com/dohonext/SimpleServerJava 에서 프로젝트를 Fork하거나 Zip file을 다운받아 압축을 풉니다.
2. Eclipse(JAVA EE) - Project Explorer - Import - General - Existing project into workspace 순으로 클릭한 뒤 폴더를 임포트합니다.
3. Root URL 을 설정하려면 Router 클래스의 13번째 라인에서 @WebServlet("/") 을 수정합니다. ex> @WebServlet("/API/") 수정하지 않으면 "/" 에서 바로 URL과 메소드가 매핑됩니다.
4. MethodHandler 클래스에서 메소드를 생성하면 메소드 이름에 따라 URL과 HTTP METHOD가 매핑됩니다. ex> 'http://YOUR_DOMAIN/user' (GET) -> userGet() 'http://YOUR_DOMAIN/article' (POST) -> articlePost() URL과 매핑되지 않을 Method는 Private으로 설정합니다.
5. DatabaseManager 클래스에서 DB 주소와 ID, Password를 설정합니다.
6. DatabaseManager 객체를 생성하고, 쿼리를 세팅하고, ? 부분에 들어갈 PreparedStatement를 설정합니다. ex> "SELECT * FROM USER WHERE uid = " 일 경우 DatabaseManager dm = new DatabaseManager(); dm.setQuery("SELECT * FROM USER WHERE uid = ?"); // 가변조건절에 '?' 사용 dm.setConditions(request.getParameter("userId"); // 파라미터 개수는 0 ~ 100개까지 가능합니다. 조건문이 필요없는 쿼리일 경우 이 메소드를 실행하지 않아도 됩니다. dm.select(); // select(), insert(), update(), delete() 를 사용할 수 있습니다.
7. 개발이 완료되면 Project Explorer - Export - Export WAR 로 익스포트하여 톰캣에 디플로이합니다.

##백로그

1. URL 매핑 다양화

• 계층구조 (/user/new :GET -> user_newGet())
• 파라미터 추가 (/user/{userID})

2. DB return message 추가
3. SetPreparedStatement 타입 추가

##개발자의 생각

1. 자바 개발자가 대부분을 차지함에도 불구하고 스타트업에서 RoR이나 Node.js등의 프레임웍이 주로 사용되는 이유
   (1) 싱글스레드 기반 웹서버의 성능적인 우위 -> 이부분은 크지 않다고 생각합니다.(개인적인 생각)
   (2) 초기 개발 생산성의 우위

   • iOS/안드로이드의 부상으로 프론트엔드가 다양화되면서 서버에서 View를 만들어 뿌려주는 방식보다
     서버에서 JSON 포맷으로 API를 뿌려주면 다양한 프론트엔드에서 클라이언트가 View를 만들어 주는 방식이 유리하다.
     그에 따라 소규모 프로젝트의 경우에 웹페이지에서도 AJAX통신과 JSON 포맷의 사용이 빈번해져서,
     프론트엔드 - 서버 - DB까지 Javascript와 JSON 포맷의 동형성을 확보한 이른바 MEAN Stack의 생산성이 높아졌다.
   • RoR 이나 Node.js등의 프레임웍의경우 서버 개발에 필요한 많은 모듈의 장착이 자동화 되어 있고,
     서버의 포트 설정, URL 매핑, API 세팅 등등이 자동화 되어있거나 간단하다.
     특히 비즈니스 로직이 복잡하지 않은 소규모 프로젝트에 주로 사용되기 때문에,
     URL과 function을 간단히 1:1로 매칭하여 function 하나에서 간단히 API 하나를 처리하는 것처럼 보인다.
   • MongoDB와 같은 DB를 사용함으로써, 쿼리문을 복잡하게 작성하지 않고 데이터를 입출력하는 것처럼 보인다.

2. JAVA의 초기 개발 생산성이 정말 떨어질까?
   (1) JAVA의 초기 개발 생산성이 떨어지는 이유는, JAVA 자체의 특성보다는 (다분히 순환론적으로) JAVA가 엔터프라이즈급
   프로젝트를 개발하는 데 주로 쓰였기 때문이라고 생각합니다. 대규모의 프로젝트에서는 고도의 확장성과 객체지향성을 담보하는 것이 개발 및 유지 보수에 유리하기 때문에, 주로 대규모 프로젝트 위주로 코드의 예제나 프레임웍이 발달하였고, 그러한 방법론을 소규모 프로젝트에 그대로 적용시키고 있으면서 "JAVA는 생산성이 낮다"라고 평하는 것이 아닌가 하는 생각입니다. 소규모 프로젝트의 여러 클라이언트에 대응할 수 있는 API 서버를 제작한다고 하면, JAVA로도 충분히 생산성을 높이 가져 갈 수 있다고 생각합니다.
   (2) URL에 매핑된 Controller에서 파라미터들의 값을 받아 객체에 매핑 -> 비즈니스 로직 처리를 위해 Biz로 객체 패스 -> 비즈니스 로직 처리 후 DB에 넣기 위해 데이터 접근 객체 Dao 에 패스 -> 쿼리스트링으로 변환하여 DB에 입력 혹은 출력하여 Dao에 리턴 -> Dao가 받아서 Biz로 리턴 후 비즈니스 로직 처리후 Controller로 리턴 -> Controller가 response.
   이 모든 과정에서 데이터는 객체에 담깁니다. 사실 비즈니스 로직이 복잡하지 않은 소규모 프로젝트의 경우, 이러한 복잡한 과정을 거치지 않고 하나의 함수에서 처리해도 충분한 경우가 많습니다. Node.js로 진행되는 소규모 프로젝트의 경우 파라미터를 받아 간단한 로직 실행 후에 db.insert(); 하는 식으로 처리합니다. 사실은 함수 내에서 새로운 객체를 불러오는 식으로 그러한 과정을 처리하지 않고 하나의 함수 내에서 다 처리하는 것 뿐이기 때문에, 이부분은 오히려 단점에 가깝습니다. 다시 말해, JAVA의 경우에도 충분히 이런식으로 하려면 할 수 있다는 뜻이 됩니다. 객체지향적이지 않아서 생산성이 높았던 것 뿐이라면 JAVA도 객체지향성을 버리기만 하면 된다는 생각입니다. JAVA에서는 파라미터로 받아온 데이터의 순수성을 담보하기 위해 데이터 객체에는 생성자와 getter만을 사용하는데, 그점을 포기하고 데이터 스트링에서 파라미터를 파싱해서 바로 로직을 처리한다면 그 부분에서 낮아지는 생산성도 그대로 높일 수 있습니다.
   (3) Database Access의 문제: 사실 NoSQL 의 경우 일견 DB I/O가 간단한 듯 보이지만, 그렇게 간단한 입출력은 SQL에서도 충분히 간단합니다. 또한 MongoDB와 같이 간단히 임포트하여 쓸 수 있는 DB의 경우에도, 사실 상용 서비스라면 join등의 명령문이 필수적으로 쓰일 수 밖에 없고, 그렇게 되었을 경우에 서버 개발자들이 SQL 쿼리문을 작성하는 것보다 더 어려운 경우가 생깁니다. (아직 대형 프로젝트에선 필수적이라고 생각하지만) 이전에는 객체위주의 서버단과 데이터 위주의 DB단을 객체위주의 서버단으로 편입하는 ORM을 통해 해결했다고 생각합니다. (감히 제가 ORM을 어떻게 해 보려는 것은 아니고..) 초보 개발자의 경우에는 select(*).from(user).. 등의 ORM 메소드 체이닝을 작성하기 위해 거꾸로 쿼리문을 먼저 작성한 뒤 그 쿼리스트링을 다시 ORM문법으로 역번역하는 것을 종종 보게됩니다. 쿼리문 작성에 그나마 조금 더 익숙하다는 전제 하에, 어차피 소규모 프로젝트라면 쿼리문이 크게 복잡하지 않을 것이기 때문에 이 프레임웍의 경우에는 그냥 setQuery 메소드를 통해 쿼리스트링을 작성하는 식으로 놔두었습니다.
   Dao 객체의 리팩토링을 통해 최대한 간단히 입출력 할 수 있도록 시도해 보았습니다. DB에서도 JAVA 메소드에 데이터를 리턴할 때, JSON 포맷의 스트링을 리턴하도록 코드를 작성했습니다. JAVA단에서 Controller가 Dao를 통해 객체로 받지 않고, 통합된 하나의 메소드가 리턴받아서 파싱하여 로직을 처리할 수 있도록 하였습니다. 어차피 Node.js등에서도 JSON.Parser 등의 함수를 사용하기에, 그것과 최대한 비슷하게 구현해 보았습니다. (JAVA단에서 JSON 포맷의 데이터를 그대로 받아 가공하고 처리하는 데에는 Gson 라이브러리를 사용하였습니다.)
   (4) "닭 잡는데 소 잡는 칼을 쓰면서 왜 자꾸 칼이 무겁다고 하지?" 라는 의문이 들었을 때, JAVA로도 충분히 닭 잡는 경량의 칼을 만들 수 있다고 생각하였습니다. 재밌게도, 대규모 프로젝트의 유지 보수성을 위한 여러가지 장치를 제거하는 것만으로도 소규모 프로젝트에서의 생산성을 담보할 수 있었습니다. 결국 Node.js와 JAVA의 프레임웍의 차이는 언어적 특성보다는, 그 철학과 방법론에서 차이가 벌어진 것이고 Node.js의 방법론을 JAVA로 구현한다면 비슷한 생산성이 나올 수도 있다는 결론에 도달하게 되었습니다. 그리고 Node.js에서 순차적 로직을 구현할 때마다 싱글스레드 프레임 루프를 계속해서 도는 것에서 기인하는 콜백 처리도, JAVA에서는 (의도하지 않으면) 할 필요가 없기 때문에 그 부분에서는 오히려 우위를 점할 수 있다고 생각합니다. 싱글 스레드 기반의 서버와와 멀테 스레드 기반의 서버는 용도에 따라 다른 것이지 절대적인 우열을 따질 수 없는 영역이기에, 코드 생산성을 위해 Node.js를 선택했을 때 반드시 싱글스레드 기반밖에 선택지가 없는 것도 좋지 않다고 생각했습니다. 초기 코드 생산성을 비슷하게 맞춰 놓으면 싱글스레드 기반 서버와 멀테스레드 기반 서버 중에서 선택할 수 있을것이고, 이런저런 장치들로 개발자로 하여금 동형성이 확보된 것으로 느낄 수 있게 할 수 있다고 생각했습니다. (5) 정통 자바 개발자님이 보시기에 "아니 뭐 이런 코드가 다 있지;;" 하고 당황하실 만한 허접한 코드를 작성해 두고 코드보다 글이 길어진 점에 대해서 진심으로 죄송스럽게 생각하고, 읽어주셔서 진심으로 감사합니다.