-

이번에는 저번에 만들었던 회원 서비스 기능을 테스트를 할 것입니다. 테스트할 때에도 아주 유용한 단축키가 있습니다. 클래스에 마우스를 대고 Ctrl + Shift + T를 누르면 Create new Test가 뜹니다. name도 그대로 MemberServiceTest라고 자동 입력되어있으니 정말 편하네요. 밑의 join, findMembers, findOne을 모두 체크해주고 OK누릅니다. 그럼 이렇게 메서드가 생성됩니다. 자 하나씩 채워넣어 봅시다. 제일 먼저 회원가입이 잘 되는지 보겠습니다. 보통은 영어권에서 취업하지 않는한 국내 기업들은 메서드명을 쓸 때 한글 이름도 많이 씁니다. 언제까지고 영어도 못하는데 findmembers, findmember, savemember이렇게 메서드를 만들면 외국인..

자 이제 이어서 회원 서비스 클래스를 개발해보려고 합니다. 회원 서비스는 회원 레포지토리랑 도메인을 활용해서 비즈니스 로직을 작성할 수 있습니다. 자 그래서 다음과 같이 service 패키지를 생성 후 클래스를 생성합니다. 회원 서비스를 만드려면 회원 레포지토리가 제일 우선적으로 있어야 합니다. 그래서 MemoryMemberRepository의 자식인 MemberRepository를 상속해서 가져옵니다. 여기서 MemberRepository가 인터페이스였고 MemoryMemberRepository는 부모 클래스였습니다. 그리고 이렇게 작성을 할 것인데, /**라고 입력하면 자동으로 파라미터 등을 입력하게끔 나옵니다. 또한 Id를 Long타입으로 선언했었기 때문에 return도 Long타입이 되어야 하므로..

계속 이어서 테스트 케이스를 작성해봅시다. 지난 번에 테스트한건 save() 메서드에 대해서 테스트 해보았습니다. 이번엔 findByName()메서드를 한 번 테스트 해봅시다. 마찬가지로 save()메서드 아래에 findByName()메서드를 만들어서 연습을 해봅시다. 똑같이 test 어노테이션을 걸겠습니다. 그리고 여기서 꿀팁이 있는데, Shift + F6을 누르시면 아래 메서드의 메서드명만 바꿀 수 있습니다. 손쉽게 member2로 바꾸고 setName에는 22222를 넣어봅시다. 이렇게하면 11111이라는 회원과 22222라는 회원이 가입이 된겁니다. 이렇게 입력하면 result에 11111이라는 회원을 찾아서 꺼내옵니다. 그 다음에 이렇게 입력하고 돌리면 findByName()에 정상적으로 녹색불..

이제부터 실습에 들어가보려 합니다. 그래서 몇 가지 고객의 정리된 요구사항을 보며 어떻게 개발을 할지 생각해봅시다. 회원 도메인과 레포지토리 만들기 회원 레포지토리 테스트 케이스 작성 회원 서비스 개발 회원 서비스 테스트 비즈니스 요구사항은 가장 쉬운거로 해볼 것입니다. 데이터 : 회원 ID, 이름 기능 : 회원 등록, 회원 조회 만으로 해보겠습니다. 저희는 아직 데이터 저장소를 선정하지 않았다고 해봅시다. 성능이 중요한 DB를 쓸지, 아니면 관계형 데이터베이스인 RDBMS로 할지를 안정해져있는데 개발을 해야한다면 어떻게 할지를 특정합니다. 일반적으로 웹 애플리케이션의 계층 구조는 다음과 같습니다. 그림에서 등장하는 컨트롤러는 웹 MVC와 컨트롤러의 역할을 합니다. 지금까지 쭉 다뤄왔던 내용입니다. 서비..

이번 시간엔 스프링 웹 개발에서 이야기 하는 API방식에 대해 다뤄보겠습니다. 이전에 봤던 MVC방식에서 봤던 VIEW를 찾아서 템플릿 엔진을 통해서 화면을 렌더링해서 HTML을 브라우저에 넘겨주는 방법이 있고 그 다음에 API를 쓰는 방식이 있습니다. 결론적으로 정적컨텐츠를 제외하면 2가지만 기억하시면 되겠습니다. 하나는 HTML로 내리던지, 아니면 API방식으로 데이터를 내리는지로 구분할 수 있겠습니다. 자 직접 보면서 이해해보겠습니다. 예전처럼 Controller에 다음과 같이 입력해보겠습니다. 여전히 GetMapping에 들어갈 내용은 메서드와 동일해야하며 -로 구분한 부분의 뒤는 대문자로 입력해주셔야 합니다. 그리고 RequestParam은 저번 시간에도 설명했듯이 RequestParameter..

MVC라는건 Model - Controller - View의 줄임말이라고 지난 포스팅에서 설명했었습니다. 과거에는 Controller와 View라는 것이 따로 분리되어 있지 않았습니다. View에 모든걸 다 넣어서 개발을 했었습니다. 하지만 요즘은 MVC로 많이 개발하고 있는 추세입니다. 왜냐하면 View는 개발할 때 화면을 그리는데 모든 역량을 집중해야하는데 Model, Controller는 비즈니스 로직이나 내부적인걸 처리하는데 집중해야합니다. 그래서 View를 MVC라고 쪼개게 됩니다. 그러니까, 갈수록 코드의 수는 많아지고 View하나에 DB로직이나 컨트롤러가 막 섞여있으면 유지보수하기 상당히 까다로울 것입니다. 그것이 현재에 와서 이렇게 쪼개지게 되었고 View는 화면에 관련된 일만, 비즈니스 ..