3일동안 Spring / MVC 패턴에 대한 공부를 위해 초초미니 프로젝트를 진행하였다.

주제는 “배달의 민족”으로 정하여 아래 기능들을 구현하였다.

• 회원 가입

• 메뉴조회

• 가게 조회

• 장바구니 담기

• 포인트 충전

• 화면 출력(Console 창)

짧지만 해당 프로젝트를 진행하며 느꼈던 것들을 KPT회고 형식으로 적어본다.

Keep

MVC 분리를 잘 하였다

MVC 패턴을 공부하기 위해 시작했던 프로젝트인 만큼

• Model(Service, DAO)

• View

• Controller
  

로 명확히 나누어 설계를 하였다.

Problem

구조 변경으로 인한 시간 부족

기존에는 SpringMVC를 공부하기 위해 Dispatcher, VierResolver를 구현하였지만 안타깝게도 많은 팀원들이 Spring에 대한 이해가 없었기에 구조를 급하게 단순한 MVC 패턴으로 변경하였다.

• 시간 부족
  - Spring에 대한 기본 구조를 이해 한 후 다시 구조변경을 함에 따라 절대적 시간이 모자라게 되었다.
• 설계
  - 시간 부족으로 인해 제대로된 설계를 하지 않고 개발을 진행하였기에 구현에 시간이 더욱 오래 걸렸다.
• 시간 관계상 Main에 모든 기능을 다 넣어두고 나중에 분리해서 의존성 문제가 많이 발생하였다.

Try

• 목표 설정
• 한정된 시간과 자원을 잘 파악하고 목표를 설정해야한다.
• 설계
  - 설계만 잘해도 구현이 배로 쉬워지기에 설계에 좀 더 시간을 쏟겠다 생각했다.

---

추가 이슈

1. MVC 흐름 in JAVA

Q. 뷰가 먼저일까? 컨트롤러가 먼저일까 (본 프로젝트에서)

컨트롤러에서 시작한다고 생각한다. Controller가 View 를 호출하기 때문이다.

그렇다면 Controller가 view를 호출하는 구조를 설계한 이유는? 개발자가 개발했던 경험을 토대로 Controller가 view를 호출하여 controller로 시작하는 경우가 많았기 때문!

⇒ 그럼 왜 이 경험이 많을까? 대부분 서버를 붙인 WAS 서비스를 개발했던 경우가 많기 때문에

2. DB 접근 방식

Q. A서비스가 다른 레포지토리(DAO)를 불러도 되는가? (A서비스가 B의 레포지데이터를 부르기)

그렇게 된다면 결합도가 높아진다.

또한 Model과 Service는 서로의 존재를 알아서는 안된다.

따라서 [A controller -> B controller -> B service -> B DAO] 로 접근해야된다고 생각한다.