스프링 회원관리 예제

스프링 김영한 강사님의 강의를 듣고 따로 코드를 작성해보고 싶어서 복습겸 해본 내용을 정리하고자 한다.

 

 

일반적인 웹 애플리케이션 계층 구조

일반적인 웹 애플리케이션의 계층 구조의 모습이다.

- 컨트롤러: 웹 MVC의 컨트롤러 역할

- 서비스: 핵심 비즈니스 로직 구현 리포지토리: 데이터베이스에 접근, 도메인 객체를 DB에 저장하고 관리

- 도메인: 비즈니스 도메인 객체, 예) 회원, 주문, 쿠폰 등등 주로 데이터베이스에 저장하고 관리됨

 

각 계층에 대해서 위와 같이 간략하게 설명을 해주셨는데,

나는 Service와 Repository 코드가 거의 비슷한데 굳이 나눠서 작성하는 이유가 궁금해서 찾아보니

질문 글에 나와 똑같은 생각을 한 사람이 있었다.

 

정리를 하자면 Repository는 DB에 접근하는 모든 코드가 모여있고,

Service는 DB에 접근하는 코드는 Repository에 위임하고, 비즈니스 로직과 관련된 코드를 작성하는 공간이라고 한다.

이렇게 구분하여 작성하면 후에 코드에 문제가 발생했을 때

코드를 수정하거나 리팩토링하는 부분에서 좀 더 쉽게 접근할 수 있다고 말씀하셨다.

즉, 비즈니스 로직과 관련된 부분에 문제가 발생했을 때는 Service부분을 확인하고,

DB 접근과 관련된 문제가 발생하면 Repository 부분을 확인할 수 있다.

 

계층 구조별 폴더

아직 컨트롤러 로직은 작성하지 않았다.

 

domain.class

package com.example.springStudy.domain;

public class User {
    private String email;
    private String password;
    private String name;

    public String getEmail() {
        return email;
    }

    public void setEmail(String email) {
        this.email = email;
    }

    public String getPassword() {
        return password;
    }

    public void setPassword(String password) {
        this.password = password;
    }

    public String getName() {
        return name;
    }

    public void setName(String name) {
        this.name = name;
    }
}

domain은 실제 DB의 테이블과 매칭시키는 클래스이다.

지금 듣고 있는 기본강의에선 위 코드와 비슷하게 코드가 작성되어 있는데,

나는 get, set이 있으면 그냥 dto인줄 알고 domain은 그냥  dto구나 하고 넘겼었다.

근데 지금 정리하면서 궁금증이 들어 찾아봤는데,

domain패키지와 dto패키지를 또 나눠서 작성한다고 한다. 

그래서 내가 생각하기에 위에 부분은 dto가 아니라 entity가 맞다는 생각을 했다.

이 부분은 후에 따로 개인 프로젝트를 진행하면서 정리를 해봐야겠다.

 

repository -> UserRepositoryInterFace.InterFace

package com.example.springStudy.repository;

import com.example.springStudy.domain.User;

import java.util.List;
import java.util.Optional;

public interface UserRepositoryInterFace {
    User StoreMember(User user); // 회원정보 저장하기
    Optional<User> findByEmail(String email); // 이메일로 회원정보 찾기
    String findPassword(String email); // 비밀번호 찾기
    List<User> findAll(); // 유저정보 가져오기
}

UserRepositoryInterFace이다.

나는 비밀번호 찾기를 추가해서 작성해봤다.

 

repository -> UserRepository.class

package com.example.springStudy.repository;

import com.example.springStudy.domain.User;

import java.util.*;

public class UserRepository implements UserRepositoryInterFace{

    private Map<String, User> storeUser = new HashMap<>();

    @Override
    public User StoreMember(User user) {
        storeUser.put(user.getEmail(), user);
        return user;
    }

    @Override
    public Optional<User> findByEmail(String email) {
        return  Optional.ofNullable(storeUser.get(email));
    }

    @Override
    public String findPassword(String email) {
        return storeUser.get(email).getPassword();
    }

    @Override
    public List<User> findAll() {
        return new ArrayList<>(storeUser.values());
    }
    public void clear(){
        storeUser.clear();
    }
}

인터페이스를 상속받아 재정의하여 사용하였다.

이 부분에 DB에 접근하는 코드를 작성한다.

 

Service -> UserService.class

package com.example.springStudy.service;

import com.example.springStudy.domain.User;
import com.example.springStudy.repository.UserRepository;

import java.util.List;
import java.util.Optional;

public class UserService {
    private UserRepository userRepository;

    public UserService(UserRepository userRepository){
        this.userRepository = userRepository;
    }

    public User join(User user){
        userRepository.StoreMember(user);
        return user;
    }
    public Optional<User> searchUser(String email){
        return userRepository.findByEmail(email);
    }
    public String findPassword(String email){
        return userRepository.findPassword(email);
    }
    public List<User> findAllUser(){
        return userRepository.findAll();
    }

}

service코드를 보면 DB에 접근하는 코드는 전부 repository에 위임하는걸 볼 수 있다.

또한 이 부분은 비즈니스 로직을 작성하는 부분이기 때문에

메소드명이나 변수명 등 좀 더 직관적으로 확인할 수 있도록 작성하는게 좋다고 한다.

 

참고자료 https://www.inflearn.com/course/%EC%8A%A4%ED%94%84%EB%A7%81-%EC%9E%85%EB%AC%B8-%EC%8A%A4%ED%94%84%EB%A7%81%EB%B6%80%ED%8A%B8