스프링을 처음 사용하는 개발자가 주로 만지는 디렉토리나 파일은 src / test / build.gradle 정도로 나눌 수 있다. src는 주로 코드 파일들이 있는 곳, test는 test code를 작성해서, 비즈니스 로직에 문제가 없는지 확인하는 곳, build.gradle은 내가 개발하는 비즈니스 로직에 필요한 종속성들을 명시하는 곳이다.
스프링을 사용하는 이유는 몇가지 있다. 그중 한개는 스프링에 내장 WAS가 있다는 것이다. 이 점 덕분에 개발 단계에서 쉽게 피드백해볼 수 있다. 그리고, 내장되어 있는 유틸리티 기능도 많은 편이다.
스프링부트 프로젝트를 실행하게 되면, 내장되어 있는 WAS인 톰캣 서버가 8080번 포트로 통신을 시작한다. 그럼 이제 http://localhost:8080 에서 내가 작성한 코드가 실행된다.
화면은 어떻게 보게 될까? 바로 Thymeleaf 템플릿 엔진의 도움을 받는다. https://start.spring.io 에서 생성한 스프링 프로젝트의 파일 트리를 자세히 보다보면 template라는 디렉토리를 볼 수 있다. 우리는 여기에 html 파일을 작성하고, Mapping 어노테이션을 달고 있는 메소드의 return값을 html 파일명으로 주어 view resolver가 찾을 수 있도록 한다. 이 때, 매개하는 역할이 Thymeleaf다. 방식은 MVC 방식을 채택했다. Model, View, Controller 세가지 역할 분담으로 나뉘는 방식이라 MVC다. Model은 송수신하는 데이터의 format같은 역할이다. View는 이 데이터를 어떻게 보여주는가에 대한 역할이며, Controller는 이 Model과 View 사이에서 데이터와 상호작용하여 Model과 View에게 그 결과를 전달한다.
A Association > B : A class references B class (참조)
A interitance > B : A class inherits B class (상속)
A Realization > B : A class implements B interface (구현)
A Dependency > B : A class references B class(참조)
A Aggregation > B : A 클래스와 B 클래스는 각각을 의존하는 객체가 동일하므로, 연관이 없지 않다
A Composition > B : A class belongs-to B class / B class has-a A class
Association <=> Dependency는 연관과 종속으로 이해하면 편할 것 같다. Association같은 경우는, 피의존 클래스의 변수와 원 클래스의 변수가 밀접한 연관이 있어, 수정에 민감하다. 그런 반면에 Dependency는 property와 method의 연관성으로, 피의존 클래스의 변수를 원 클래스 메소드 파라미터로 제공하는 관계로 이해하면 좋을듯.
Aggregation은 객체의 구성 요소로, 다른 연관 객체에 의해 연결되어 있지만, 각자는 직접적인 연관을 가지지 않는 관계.
Composition은 서로가 강하게 연관되어 있어, 서로 중 하나가 삭제된다면, 그 객체가 불완전해지는 경우.
실제로 개발해보는 단계이다.
- 회원 존재(이 때 회원은 그냥 회원과 VIP회원으로 등급이 나뉜다)
- 상품 주문 가능
- (추후 변동 가능) 정액 할인 기능
- DB는 아직 정하지 않았다.
우리는 객체지향의 SOLID 원칙을 생각하며 개발해야 한다. 그럼 진행 단계를 가볍게 살펴보자.
UML Class Diagram으로 우리가 필요한 클래스 간의 종속 관계를 명시해두면 개발하기 편하다. 여기서는 추후 이 페이지를 통한 재검토가 필요하지 않은 사항이므로, 생략토록 하겠다.
우리는 회원이라는 객체와 회원가입, 조회, 주문 등의 함수가 필요하다. 그럼 Repository 객체와 Service & Oreder Interface가 필요하겠다. 단, 이 Interface를 구현하는 클래스에서는, MemberRepository 객체를 직접 생성하지 않는다. AppConfig라는 파일을 따로 생성해서 생성자 주입을 통하여 각각의 구현 클래스에 의존성을 주입시킨다.