서론 🙋‍♂️

• 스프링부트로 프로필 이미지를 변경해보자 🤔 (파일 입출력)를 응용해서 파일을 업로드하고 해당 파일의 경로와 이름, 확장자 그리고 사이즈까지 저장하는 Jpa Repository 를 생성해 어플리케이션 내의 파일을 관리합니다.
• 파일을 관리할 수 있는 유틸리티 클래스를 생성해서 편리하게 가공할 수 있도록 구현합니다.

본론 🙆🏻‍♂️

전체적인 흐름은 이렇습니다.

• 파일 엔티티 클래스 생성하기
• 파일 Dto 생성하기
• 파일 Repository 생성하기
• 파일 유틸리티 클래스 생성후 정적 유틸리티 메소드 선언하기
• 서비스 클래스 생성 후, 기본적인 CRUD 테스트 코드 작성하기
• 각각 파일 입출력이 필요한 엔티티 서비스 계층에서 활용해보기
• 기본적인 파일 저장 방식은 commons-io 디펜던시를 추가하여 사용하며, DB에는 파일 자체를 저장하지 않고 경로와 이름을 저장해 출력은 바이트 어레이로 경로를 참조해 출력시킵니다.

파일 엔티티 클래스 생성하고 관련된 Dto까지 생성하기 💁🏻

yaml 파일에 commons-io 관련 설정을 입력해주고, 파일이 저장될 경로를 지정해주세요. (해당 파일 자체를 DB에 저장하지 않고 경로만 참조합니다.)

(해당 글은 Spring Data Jpa 를 사용합니다.)

@Entity
@AllArgsConstructor(access = AccessLevel.PRIVATE)
@Getter
@Builder
@NoArgsConstructor(access = AccessLevel.PROTECTED)
@ToString
public class SaveFile extends AuditingFields{
    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id;
    @Setter
    @Column(nullable = false)
    private String fileName;
    @Setter
    @Column(nullable = false)
    private String filePath ;
    @Setter
    @Column(nullable = false)
    private String fileType;
    @Setter
    @Column(nullable = false)
    private Long fileSize;
    @Setter
    @Column(nullable = false)
    private String uploadUser;

기본적으로 사용될 필드변수들을 선언해줍니다.

해당 엔티티는 기존에 설정한 파일 경로를 참조해 파일을 불러와서 출력할 예정입니다.

@Builder
    public  record FileDto (
            Long id,
            String fileName,
            String filePath,
            String fileType,
            Long fileSize,
            String uploadUser,
						LocalDateTime createdAt,
            String createdBy,
            LocalDateTime modifiedAt,
            String modifiedBy
    )  {
        public static FileDto from(SaveFile saveFile) {
            return new FileDto(
                    saveFile.getId(),
                    saveFile.getFileName(),
                    saveFile.getFilePath(),
                    saveFile.getFileType(),
                    saveFile.getFileSize(),
                    saveFile.getUploadUser(),
                    saveFile.getCreatedAt(),
                    saveFile.getCreatedBy(),
                    saveFile.getModifiedAt(),
                    saveFile.getModifiedBy()
            );}
        public SaveFile toEntity() {
            return SaveFile.builder()
                    .id(id)
                    .fileName(fileName)
                    .filePath(filePath)
                    .fileType(fileType)
                    .fileSize(fileSize)
                    .uploadUser(uploadUser)
                    .build();
        }
    }

FileDto는 레코드 형식으로 생성 주었습니다. 저 같은 경우에는 Dto가 늘어남에 따라서 엔티티 클래스 안에 정적 클래스로 생성해주어서 한 도메인이 담당하는 엔티티 클래스와 Dto 클래스들을 묶어서 관리하고 있습니다.

File 엔티티 클래스와 Dto 클래스 필드에 선언된 변수가 다른 이유는 Audititng Fields 인터페이스를 생성해서 각 엔티티 클래스속 공통적으로 들어가는 필드를 따로 분리해서 관리할 수 있게 해 줬습니다.

JPA Auditing 기능이란? <- 해당 글을 참고하시면 좋을 것 같습니다 :D\

JpaRepository 생성하고 서비스 클래스 생성하기 💁🏻

@RepositoryRestResource
public interface SaveFileRepository extends JpaRepository<SaveFile, Long> {
    public SaveFile findByFileName(String fileName);
}

JpaRepository를 상속받는 인터페이스를 생성해줍니다.
(@RepositoryRestResource 같은 경우는 Spring Data Rest 디펜던시를 추가하면 사용이 가능한데, 따로 API를 구현하지 않고도 REST API를 디펜던시가 구현해주어서 사용할 수 있게 해주는 어노테이션입니다.하지만 여기서는 사용하지 않습니다.)

@Service
@Slf4j
@RequiredArgsConstructor
@Transactional
public class FileService {

    private final SaveFileRepository fileRepository;

    public SaveFile.FileDto getFile(Long fileId) {
        log.info("getFile() fileId: {}", fileId);
        return fileRepository.findById(fileId).map(SaveFile.FileDto::from).orElseThrow(()-> new EntityNotFoundException("파일이 없습니다 - fileId: " + fileId));
    }
    public void deleteFile(Long fileId) {
        log.info("deleteFile() fileId: {}", fileId);
        fileRepository.deleteById(fileId);
    }
    public SaveFile.FileDto saveFile(SaveFile.FileDto saveFile) {
        log.info("saveFile() saveFile: {}", saveFile);
        return SaveFile.FileDto.from(fileRepository.save(saveFile.toEntity()));
    }
}

마찬가지로 JpaRepository를 생성했으니 비즈니스 로직을 설계할 차례입니다.
테스트 코드를 작성하면서 메서드를 작성 할 수 있으나 , 기본적인 추가 삭제 조회 정도만 구현하면 되기때문에 패스해도록 하겠습니다

File 유틸리티 클래스 생성하기 💁🏻

저번 글에서는 MultipartFile 인터페이스를 사용해서 파일을 받아왔고, 파일 객체로 변환하는 작업을 모두 메소드 안에서 일일이 처리했기 때문에 이번에는 유틸리티 클래스를 생성해 관리하도록 편의성을 부여해줍니다.

public class FileUtil {
    private FileUtil() {
    }
    @Value("${com.example.upload.path.profileImg}")
    public static String uploadPath;


	//확장자를 가져오는 메소드
    public  static String getExtension(String fileName) {
        return fileName.substring(fileName.lastIndexOf(".") + 1);
    }
    //파일 이름만을 가져오는 메소드
    public static String getFileName(String fileName) {
        return fileName.substring(0, fileName.lastIndexOf("."));
    }
	//UUDI값을 파일이름에 붙여줘서 가져와주는 메소드
    public static String getFileNameWithUUID(String fileName) {
        return UUID.randomUUID().toString() + "_" + fileName;
    }
    //정적 팩토리 메소드
    public  static File  createFile(String uploadPath, String fileName) {
        return new File(uploadPath, fileName);
    }

    public static File getMultipartFileToFile(MultipartFile multipartFile) throws IOException {
        File file = new File(uploadPath,getFileNameWithUUID(multipartFile.getOriginalFilename()));
        multipartFile.transferTo(file);
        return file;
    }

    public static File getFileFromFileDomain(SaveFile.FileDto fileDto) {
        return new File(fileDto.filePath());
    }


    public static void deleteFile(SaveFile.FileDto profileImg) {
        File file = getFileFromFileDomain(profileImg);
        if (file.exists()) {
            file.delete();
        }
    }
    //멀티파트파일을 파일객체로 변환후 FileDto로 리턴해주는 메소드 
    public static SaveFile.FileDto getFileDtoFromMultiPartFile(MultipartFile multipartFile, String uploadUser) throws IOException {
        File file = getMultipartFileToFile(multipartFile);
        String fileName = file.getName();
        String fileType = getExtension(Objects.requireNonNull(multipartFile.getOriginalFilename()));
        Long fileSize = multipartFile.getSize();
        return SaveFile.FileDto.builder()
                .fileName(fileName)
                .filePath("yourpath"+fileName)
                .fileType(fileType)
                .fileSize(fileSize)
                .uploadUser(uploadUser)
                .build();// TODO: 경로가 자꾸 null 로 입력되기 때문에 해결 방안을 찾아야함.
    }

맨 아래 메서드를 가장 많이 사용하게 될 것 같은데요 ,저같은 경우는 다른 메소드에서는 경로를 정상적으로 참조하는 반면에 해당 메소드는 null값으로 입력이 되어서 임시방편으로 메소드 내에 경로를 다시 선언해주었습니다.

해당 유틸리티 클래스로 각각 파일을 전달받는 컨트롤러에서 멀티파트 파일을 프런트에서 받아오면 FileDto 로 변환 후에 저장 후 필요한 객체에 Set 하는 방식으로 이용합니다.

컨트롤러에서 활용해보기 💁🏻

    @Setter
    @ToString.Exclude
    @ManyToOne
    @JoinColumn(name = "profile_img_id")
    @Nullable
    private SaveFile profileImg;

저는 유저 엔티티 필드 변수 속 단순 path와 name으로 선언해두었던 프로필 파일을 엔티티를 변수로 갖도록 변경해주었습니다.

    @PostMapping("/signup")
    public ResponseEntity<?> signup(@RequestPart("signupDto") @Valid UserAccount.SignupDto signupDto, BindingResult bindingResult
    ,@RequestPart(value = "imgFile",required = false) MultipartFile imgFile) throws IOException {
        if (bindingResult.hasErrors()) {
            return new ResponseEntity<>(ControllerUtil.getErrors(bindingResult), HttpStatus.BAD_REQUEST);
        }
        else if(!signupDto.getPassword1().equals(signupDto.getPassword2())){
            bindingResult.addError(new FieldError("userCreateForm","password2","비밀번호가 일치하지 않습니다."));
            return new ResponseEntity<>(ControllerUtil.getErrors(bindingResult), HttpStatus.BAD_REQUEST);
        }
        if(imgFile==null){
            userService.saveUserAccountWithoutProfile(signupDto);
        }
        else {
            userService.saveUserAccount(signupDto, fileService.saveFile(FileUtil.getFileDtoFromMultiPartFile(imgFile,signupDto.getUserId())));
        }
        return new ResponseEntity<>("success", HttpStatus.OK);
    }

기존에 작성해둔 메서드를 수정합니다. multipartFile 자체를 매개 값으로 전달했었으나, 이제는 유틸리티 클래스의 도움을 받아서 fileDto 로 변환 후jpaRepository에 저장 후에 식별자를 매개 값으로 넘겨주게 됩니다.

    public void saveUserAccount(UserAccount.SignupDto user, SaveFile.FileDto fileDto) throws IOException {
        String password = user.getPassword1();
        UserAccount account = userAccountRepository.save(user.toEntity());
        account.setUserPassword(new BCryptPasswordEncoder().encode(password));
        account.setProfileImg(fileDto.toEntity());
    }

그렇게 전달받은 file을 단순히 계정 엔티티에 set 해주면 됩니다.

출력해보기 💁🏻

이제 DB에 해당 엔티티를 참조할 수 있도록 구현해놨으니 출력하는 것도 구현해야 합니다.

    @GetMapping("/accounts/{username}")
    public ResponseEntity<?> getProfileImg (@PathVariable String username) throws IOException {
        File profileImg = FileUtil.getFileFromFileDomain(userService.getUserAccount(username).profileImg());
        byte[] imageByteArray = IOUtils.toByteArray(new FileInputStream(profileImg));
        return new ResponseEntity<>(imageByteArray, HttpStatus.OK);
    }

여기서도 마찬가지로 FileUtil 클래스를 이용해 엔티티를 파일 객체로 만들어줍니다.
그리고 IOUtils 클래스가 제공하는 바이트 어레이 변환 메서드를 이용해 바이트 배열로 변환해주고 객체로 전달해줍니다.

이제 이미지 출력이 필요한 부분에 src 태그에 해당 경로를 집어넣으면 프로필 사진이 출력되게 됩니다!

시연 화면 💁🏻

아무 사진 하나만 회원 가입할 때 업로드해줍니다.

이렇게 가입이 완료되면 이전과는 다르게 파일 경로와 이름이 DB에 저장되는 것이 아닌 외래 키로 다른 테이블 식별자를 참조하게 됩니다.

이렇게 파일 저장용 테이블이 만들어져서 업로드 유저와 함께 사이즈, 확장자, 그리고 경로 이름이 칼럼 값으로 들어가게 됩니다.

자 이렇게 업로드한 프로필 사진이 정상적으로 출력이 됩니다. (사진은 제 셀카예요;;)

마찬가지로 해당 로직을 응용해서 수정도 할 수 있습니다.

수정을 하게 될 경우엔 기존에 존재하던 파일을 삭제하고 새로 저장된 파일 엔티티를 참조하는 방식으로 구현했습니다.

; 자 이렇게 다른 이미지에서 또다시 원래 이미지로 변경하고 수정을 하게 되면

기존에 등록된 프로필 이미지는 삭제됩니다! 물론 deleteFile 메서드도 호출했으니 로컬에서도 삭제됩니다.

마무리 💆🏻‍♂️

• 생각보다 어려워 보였던 파일 입출력을 쉽게 구현해보았습니다.
• fileRepository 의존성 주입을 다른 클래스에서 해도 되나가 가장 큰 고민거리였습니다.
• 해당 고민은 fileservice 를 파일 입출력이 필요한 컨트롤러에서 주입받아 이용하도록 해결했습니다.
• 바이트 배열로 전달하는것 외에 더 효율적인 출력방법이 있을까요 ? 저는 아직 모르겠습니다 ;(
• A(프로필 이미지 단건 업로드) -> B (단건 참조) 까지 했으니 다음 목표는 C 게시글에 이미지 여러건 첨부 후 출력 으로 잡으면 되겠습니다! 🎅🏽

사용기술

• 스프링부트
• 제이쿼리
• 타임리프 살짝

서론

디테일하게 파일을 저장하는 레포지토리를 만들어서 해당 레포지토리에서 파일을 꺼내오는 것이 아닌 파일 입출력을 스프링 부트에서 어떻게 구현할 수 있는지에 대한 궁금증으로 인해

단순히 account 엔티티에 프로필 이미지 경로와 이름 변수를 선언해 단건으로 구현해보기로 했습니다.

해당 글에서 작성한 코드들은 다른분들의 글을 많이 참고했음을 알려드립니다.
$ 참고글

• Spring Boot | multipart/form-data 파일 업로드 ( + React , Axios, REST API, multiple files)
• [Spring Boot] 게시판 구현 하기 (4) - 파일 업로드 & 다운로드

본론

전체적인 흐름은 이렇습니다.

프로필 이미지 필드 변수가 존재하지 않는 계정 엔티티에 프로필 이미지용 경로/ 이름 변수 선언해주기
👇🏻
엔티티에 필드변수가 추가되었으니 관련된 웹 계층/서비스 계층 테스트 코드 작성 후 다듬기
👉🏻 프로필 이미지가 업로드가 되었을 때 안되었을 때두 가지 케이스로 살펴보자.
👉 스프링 시큐리티에서 리소스에 대한 접근을 허용하도록 코드를 추가해주어야 한다.
👇🏻
앞단에서 제이쿼리로 파일 업로드받아서 뒷단으로 넘겨주기
👇🏻
타임리 프로 해당 프로필 이미지 출력하기

계정 엔티티 수정하기

지금 상황은 게시판 홈페이지에 프로필 이미지 관련 기능이 하나도 구현되어있지 않은 상황이므로 무에서 유를 창조해야 합니다. 👀

일단 파일 업로드 관련 디펜던시를 build.gradle 에 추가해주고 어느 경로에 업로드된 파일을 저장해줄지 yaml파일에 지정해줍니다.

dependencies {
	implementation('commons-io:commons-io:2.11.0')
    }

    multipart:
      max-file-size: 10MB
      max-request-size: 10MB
      location: /Users/brinc/Desktop
      enabled: true
com.example.upload.path.profileImg : /Users/brinc/Desktop 

절대 경로로 작성해야 합니다.

그리고 기존에 생성돼있는 계정 엔티티에 이미지 파일의 경로와 이름을 필드 변수로 선언해줍니다.

...
    @Setter private String profileImgName;
    @Setter private String profileImgPath;
...

계정 엔티티와 연관된 Dto에도 파일 경로를 추가해줄 수 있지 않을까? 하는 생각이 있었는데, 여러 시도 결과 @RequestPart로 회원가입 리퀘스트 Dto와 파일을 따로 요청받도록 했습니다.

제 실력선에서는 프런트단에서 업로드 시에 폼 데이터를 하나의 Dto로 전달받을 때 파일은 파일로, 양식은 json 타입으로 전달받는 방법을 찾지 못했습니다 😿

컨트롤러 내 회원가입 메서드 수정하기

이제 디펜던시와 엔티티도 수정을 해주었고, 뷰는 단순히 태그만 추가해줘도 되기 때문에 컨트롤러 내에 있는 메서드부터 수정해줍니다.

   @PostMapping("/signup")
    public ResponseEntity<?> signup(@RequestPart("signupDto") @Valid UserAccount.SignupDto signupDto, BindingResult bindingResult
    ,@RequestPart(value = "imgFile",required = false) MultipartFile imgFile) throws IOException {
        if (bindingResult.hasErrors()) {
            return new ResponseEntity<>(controllerUtil.getErrors(bindingResult), HttpStatus.BAD_REQUEST);
        }
        else if(!signupDto.getPassword1().equals(signupDto.getPassword2())){
            bindingResult.addError(new FieldError("userCreateForm","password2","비밀번호가 일치하지 않습니다."));
            return new ResponseEntity<>(controllerUtil.getErrors(bindingResult), HttpStatus.BAD_REQUEST);
        }// -----추가된 부분-------
        if(imgFile==null){
            userService.saveUserAccountWithoutProfile(signupDto);
        }
        else {
            userService.saveUserAccount(signupDto, imgFile);
        }
        return new ResponseEntity<>("success", HttpStatus.OK);
    }

제 목적은 최대한 기존의 코드의 큰 변경이 없이 기능만 추가할 수 있는 걸 원했기 때문에, 회원가입 관련 메서드만 수정해주면 되었습니다.

기존의 코드에서 이미지 파일이 존재한다면 디폴트 이미지로 프로필 이미지를 설정하도록 했고, 존재한다면 이미지 파일을 같이 받아와서 서비스 계층으로 넘겨주도록 코드를 추가했습니다.

비즈니스 로직 수정하기

이제 컨트롤러에서 서비스 계층으로 전달하는 값이 추가되었으니, 해당 값을 또 가공해서 디비에 반영해야 하니 메서드를 수정해야 합니다.

    public void saveUserAccount(UserAccount.SignupDto user,MultipartFile imgFile) throws IOException {
        String password = user.getPassword1();
        UserAccount account = userAccountRepository.save(user.toEntity());
        account.setUserPassword(new BCryptPasswordEncoder().encode(password));
        // ----- 추가된 부분 -----
        UUID uuid = UUID.randomUUID();
        String fileName = uuid.toString() + "_" + imgFile.getOriginalFilename();
        File profileImg=  new File(uploadPath,fileName);
        imgFile.transferTo(profileImg);
        account.setProfileImgName(fileName);
        account.setProfileImgPath(uploadPath+"/"+fileName);
    }

파일을 저장할 때는 랜덤 한 UUID를 생성해 이름에 부여합니다. (같은 이름을 가진 파일을 업로드할 때 오류가 생기면 안 되겠죠?)
그리고 UUID를 붙여서 새로 지정한 이미지 파일 이름과 경로를 기준으로 파일 객체를 생성합니다.

그리고 뷰에서 전달받은 파일을 multipartfile 클래스가 제공하는 transferTo 메서드로 파일 객체로 변환해줍니다.

그리고 간단하게 해당 엔티티의 프로필 이미지 경로와 이름을 업데이트해주면 됩니다!

회원가입 폼에 이미지 파일 업로드 태그 추가하기

이제 대충 뒷단은 구현했으니 앞단을 수정할 차례입니다.

<form method="post" style="width:700px"  enctype="multipart/form-data">
  <p class="register">회원가입</p>
  <label for="imgFile">프로필 사진</label>
    <input type="file" name="imgFile" id="imgFile"  accept=".jpg, .png" class="form-control">
    ...

단순히 기존에 작성돼있던 폼에 enctype을 추가해서 폼 데이터로 전송할 것을 명시해주고, 프로필 사진을 업로드해야 할 부분에 input 태그로 type을 file로 지정해주면 됩니다.

accept 에는 확장자를 입력하면 해당 확장자가 아닐 경우에 업로드를 하지 못하게 해 줍니다.

그리고 해당 값을 제이쿼리를 이용해서 컨트롤러로 전송합니다.

function signupCheck() {
    var formData = new FormData();
    formData.append("imgFile", $("#imgFile")[0].files[0]);
    var data = {
        info: {
            userId: $("#userId").val(),
            password1: $("#password1").val(),
            password2: $("#password2").val(),
            nickname: $("#nickname").val(),
            email: $("#email").val(),
            memo: $("#memo").val()
        }
    }
    formData.append(
        "signupDto",
        new Blob([JSON.stringify(data.info)], { type: "application/json" })
    );
    console.log(formData);
    //위에서 만든 오브젝트를 json 타입으로 바꾼다.
    $.ajax({
        type : 'POST',
        url : '/signup',
        data : formData,
        processData : false,
        contentType : false,
        success: function ( ){
            alert("회원가입 성공");
        },

저는 기존에 작성해뒀던 스크립트를 수정해서 사용했습니다.
formData 객체를 새로 생성해서 사용합니다.
객체의 첫 인덱스에는 이미지 파일을 담아주고, 두 번째 인덱스에 입력했던 값들을 json형태로 변환해서 담아줍니다.

키값에 입력되는 이름이 RequestPart 어노테이션의 이름에 들어갈 값과 같아야 합니다.

컨트롤러에 프로필 이미지를 가져와줄 메서드를 선언하자

프런트에서 해결해야 할 부분이 하나 더 남았는데, GET 메서드로 프로필 이미지를 바이트 배열로 전달받아야 합니다.

단순히 src태그에 경로를 붙여버리면, 빌드 전에 이미 존재하던 파일이 아닌 이상 읽어오지 못합니다.

    @GetMapping("/accounts/{username}")
    public ResponseEntity<?> getProfileImg (@PathVariable String username) throws IOException {
        UserAccount.UserAccountDto accountDto = userService.getUserAccount(username);
        InputStream inputStream = new FileInputStream(accountDto.profileImgPath());
        byte[] imageByteArray = IOUtils.toByteArray(inputStream);
        inputStream.close();
        return new ResponseEntity<>(imageByteArray, HttpStatus.OK);
    }

inputstream으로 파일을 읽어와서 바이트 배열로 전달해줍니다.

그리고 해당 프로필 이미지가 출력되어야 하는 부분에는 타임리프 문법인 th:src를 사용해서 이미지를 출력해줄 겁니다.

<img id="imgId" th:src="@{/accounts/}+${accountDto.userId}" width="100" height="100"  alt="첨부이미지" th:if="${accountDto.profileImgPath() != null}" />

동작하는지 확인해보기

파일을 업로드해줍니다. accept에 png와 jpg 만 받도록 명시해놨기 때문에 해당 파일 외의 파일들은 업로드하지 못합니다.

이렇게 새로 생성한 계정에 yaml 파일에 지정해둔 경로에 이미지가 업로드된 모습을 볼 수 있습니다. (파일을 업로드하지 않을 때는 단순히 같은 메서드에 default 이미지의 경로와 이름을 대입해주면 됩니다 🤓)

제가 임시로 만들어둔 페이지입니다. 이미지를 잘 출력하는 모습을 볼 수 있습니다

마찬가지로 이렇게 비슷한 패턴으로 프로필 수정 페이지를 구현해서 프로필 이미지를 변경할 수도 있습니다.

잘 변경이 되네요 😎

마치며

• 입출력 스트림을 활용해보고 싶어서 시도해보았으나, 딥한 원리를 이해하지 못하고 구현한 느낌이 들어서 게시글 이미지/파일 첨부 기능 구현시에 좀더 딥하게 공부해볼 예정입니다.
• 해당 기능을 구현하면서 겪었던 오류는 절대경로를 제대로 지정하지 않아 발생한 오류와, 이미지 파일 출력을 단순 절대경로로 출력하려고 할때 없는 파일로 인식이 되어 발생한 오류 이렇게 총 두가지 입니다.
• 해당 기능을 구현할때 좀 더 살펴보면 좋은것은 MultipartFile 인터페이스가 어떠한 기능을 제공해주고 어떻게 돌아가는지 공식 문서를 참고하면 좋을 것 같습니다.
• 단순히 파일 자체를 dto 로 전달받아 업로드 하는 방식도 있습니다만 저는 제이쿼리로 기존의 회원가입 폼을 만들었기 때문에 제이쿼리로 전달하는 방법을 찾아보았습니다.
• 제이쿼리 스크립트 속 blob 은 [Javascript] API 활용 - Blob 해당 글을 참고하시면 좋을것 같습니다 :)

죽음의 프로젝트 주제 💀

진행 기간 2022-11-25~2022-12-07 (저는 구체적인 프로젝트 설명이 진행되기 이전에 제 실력을 기르고자 먼저 시작했고, 2일 동안 진행했습니다.)

고객 분류 프로그램 개발 💡

스토어 사장님들을 위한 고객을 이용시간 별로 분류하고 나눠서 원하는 정보대로 정렬 / 출력 할 수 있는 프로그램을 개발한다.

유의사항 💡

• 컬렉션 프레임워크 사용 금지 (단 Arrays 는 허용) 🚫 List,Set,Map 등에 대한 API를 직접 구현해야 한다.
• 고객별로 이용시간, 이용금액에 따라서 분류가 가능해야 한다.
• 분류된 데이터를 이름순, 이용금액, 이용시간 기반으로 정렬이 가능해야 한다.
• 고객의 정보를 추가,수정,삭제,조회가 가능해야 한다.
• 분류 기준을 수정,초기화 할 수 있어야 하고 수정될 시에 수정된 기준으로 다시 분류가 가능해야 한다.
• 객체지향 성격이 잘 드러날 수 있도록 클래스를 설계해야 한다.

클래스 설계 🧑🏻‍💻

(클래스 관계는 기존에 프로젝트 정의서에 있던 내용들을 참고하였으며, 역할은 제 맘대로 지정했습니다.)

• Customer 도메인 (고객 정보에 대한 모든것을 담당한다.) 🧑🏻‍💻
  • Customer : 고객들의 정보를 담고있는 객체를 생성하기 위한 클래스
    • 객체 생성자, 기본적인 Getter, Setter 그리고 자바빈 규약을 따른 멤버변수를 선언했습니다.
  • Customers : Customer 객체를 저장하고 관리하기위한 클래스
    • Customer 객체를 생성, 수정, 조회, 삭제 하기 위한 배열을 갖고 있고, 그룹 기준별로 등급을 설정, 등급별로 그룹을 나눠서 리턴해주는 기능까지 구현했습니다.
  • ClassifiedCustomers : 등급별로 분류된 Customer 를 정렬하고 출력하기 위한 클래스
    • 기존의 ClassifiedCustomers 는 분류된 고객들 이라는 뜻을 갖고있기 때문에 분류된 고객리스트가 관리를 하는것은 이상하지 않을까? 라는 생각으로 Customer 가 해당 그룹핑을 관리하도록 역할을 정했습니다.
• Group 도메인 🧑🏻‍💻
  • Group : Customer과 마찬가지로 그룹에대한 정보를 담고있는 객체를 생성하기 위한 클래스
    • Enum타입인 GroupType 과 , 분류 기준인 Parameter 를 멤버변수로 갖고 있습니다.
  • GroupType : Enum타입으로 분류가 안된 NONE 타입, 일반 등급인 GENERAL, 그리고 VIP, VVIP 이렇게 4개의 타입이 정의되어있다.
  • Parameter : 그룹 기준을 설정할 객체로, 멤버변수로는 기준이 될 이용시간과 이용금액이 선언되어있고, 해당 기준을 초과하면 해당 등급이 된다.
  • Groups : Group을 담을 배열을 갖고있는 관리 클래스. 등급을 분류할 그룹은 이미 정해져있고, 초기화가 되지 않아서 각각 0시간과 0만원의 파라미터를 담고있는 그룹이 4개가 배열에 들어가있다.
• Menu 도메인 🧑🏻‍💻
  • Menu 인터페이스 : 각각 메뉴가 기본적으로 가지고 있는 행동들을 메소드로 선언한다.
    • Menu를 구현한 구현클래스 : 기본적인 첫 메뉴를 담당할 클래스
    • CustomerMenu : Customer에 대한 입력 유도문과, Customer 객체를 생성하기 전 데이터 검증과, 비즈니스 검증까지 담당한다.
    • GroupMenu : 등급에 대한 기준 초기화, 수정, 조회 를 입력유도문을 통해 원하는 등급을 입력받고 해당 결과물을 출력해준다.
    • SummaryMenu : 분류된 등급에 따라 고객 명단을 출력해주고, 원하는 데이터에 따라 오름차순/내림차순 으로 목록을 출력해준다.

본격 코딩 들어가기 🤦🏻‍♂️

해당 토이프로젝트 주제는 무엇보다 객체지향 설계와 프로그래밍이 가장 큰 주제였다고 생각했습니다.

그리고 +@로 싱글톤으로 관리할 수 있는 객체들은 싱글톤 패턴으로 관리해, 스프링에서 자주나오는 객체 주입까지 체험해볼 수 있는 아주 유익한 프로젝트라 생각했습니다.

Customer 도메인 🗓️

일단 해당 클래스가 어떠한 역할을 갖고 있는지, 그리고 어떠한 부분까지 담당할 수 있을지를 처음에 고민을 많이 했습니다.

저는 일단 객체를 만들기 위한 Customer 클래스는 단순히 Customer객체에 대한 설계도 라는 역할만 갖고 있길 바랐으며,

Customers 클래스는 해당 객체! 만 관리! 하는 클래스 정도의 역할만 갖고 있길 바랐습니다.

(기본적인 ~~를 입력해주세요. 라는 부분은 Menu에서 담당하고, 말 그대로 등록/조회/수정/삭제에서 조금 더 나아가 해당 클래스에서 분류/ 그룹핑, 그리고 직접 API를 구현해야 했기 때문에 그에 따른 배열 관리 메서드 (trimToSize 나 더블링) 정도까지만 갖고 있도록 설계했습니다.)

ClassifiedCustomers 클래스에 대한 생각이 꽤 많았는데요, 강사님께서 제시해주신 클래스 다이어그램에서는

싱글톤으로 관리해야할 Customers를 배열에 담고 계셨었습니다.

최대한 주어진 설계도에 맞춰서 작업하는 게 추후에 제가 서비스를 제작해주길 원하는 고객이 기본적인 설계도를 가져온다면, 그거에 최대한 맞게 작업하는게 맞다고 생각을 했었습니다.

고민되었던 문제.. 🫠

• Customers 객체를 싱글톤으로 관리하는데 (왜냐하면 하나의 리스트로 관리하고 싶기 때문에) 해당 객체를 배열에 저장할 수 있을까?
  • 해당 부분은 아직 해결되지 않을 상태였습니다. 하지만 제 나름대로 생각을 좀 해서 2차원 배열로 그룹핑을 해 ClassifiedCustomers에 해당 배열을 저장하도록 진행했습니다. 🥹
• Customer객체를 생성하기 위한 검증을 Customers에서 진행해야 할까 아니면 Menu에서 진행해야 할까?
  • 담당 역할에 대해서 고민이 많았습니다. 스프링으로 따지자면 Customers는 Repository 같은 경우였고, menu는 service계층 이라고 생각했기때문에 Menu에서 검증을 진행하도록 설계했습니다. 😇
• ClassifiedCustomers의 존재이유 .. 🤔
  • 이미 Customer 객체가 Group이라는 변수를 갖고있는데 그걸 또 다시 나눠야하는 이유가 궁금했습니다.
  • 설계는 알아서 해도 되기때문에 1차적으로는 ClassifiedCustomers 클래스를 생성하지 않고, 그룹별 정렬/출력을 해당 클래스에서 담당하도록 설계했습니다.
  • 하지만 추후에 생각을 해보니 이 방식은 매 그룹마다 처음부터 끝까지 탐색을 하며 값을 골라서 출력하도록 하는 로직이었기 때문에 비효율적이라 생각해 Classified 클래스를 생성해 배열을 전달받도록 구현했습니다.

Group 도메인 👨‍👩‍👧‍👧

해당 도메인은 하나하나가 큰 역할을 갖고 있다기보다는Customer가 필요하기 때문에 있어야 하는 Class 정도로 다가왔습니다.

단순히 Group은 분류 기준과 타입(어떻게 보면 그룹 이름)만 갖고 있기 때문에, 해당 Group들을 관리할 Groups 클래스는 Customers처럼 조회, 삭제, 수정, 추가를 구현하지 않고 이미 있는 그룹의 기준을 초기화, 수정, 조회만 가능하도록 구현했습니다. 그리고 별 차이 없이 프로젝트 정의서 속 설계도와 거의 일치하게 설계했습니다.

Group 클래스는 단순히 해당 그룹을 정의할 Enum타입 GroupType과, Parameter를 멤버 변수로 갖고 있습니다.

Parameter는 고객들을 분류하기 위한 기준을 담고 있습니다. 기준 이용금액, 기준 이용시간을 멤버 변수로 갖고 있으며 해당 기준을 초과하면 해당 등급의 멤버가 됩니다.

Groups 클래스는 Customers와 같이 Group을 관리할 클래스로서, 해당 객체가 생성될 때 생성자는 각 배열 인덱스에 0,0 값(이용 기준)을 담고 있는 깡통 그룹 객체를 담고 생성하도록 해줍니다.

고민되었던 문제..🫠

• Group에 대한 역할이 애매모호 했습니다. 이것으로 고객을 담아야할지? 아니면 단순히 그룹타입을 Customer 클래스에 선언해서 해당 Enum으로만 관리하고 다른 설계도만 Group에 담아도 되지않을까.. 하는 고민이 있었으나, 단순 이름표 같은거라고 생각하고 최대한 설계도에 맞게 설계했습니다.

Menu 도메인 🖱️

Menu도메인은 각각 클래스별로 실행하는 행동들은 같지만, 그 내용물은 다를 것이기 때문에 Menu인터페이스를 구현하도록 설계했습니다.

Menu 인터페이스는 기본적인 메뉴를 출력하는 ShowMenu와, 해당 메뉴를 골랐을 때 나올 반응인 SelectMenu 메서드를 선언했고,

나머지 메뉴 클래스들은 해당 역할에 맞도록 재정의해서 메서드를 선언해줬습니다.

첫 번째 화면이 될 MenuImpl 클래스는 어떻게 보면 다른 메뉴들의 조상이라고 할 수 있어서 부모 클래스로 생성할지를 고민했지만, 그렇게 하면 다른 메뉴 객체를 싱글톤으로 관리할 수 없기 때문에 단순 구현 클래스로 지정해주었습니다.

기본적인 첫 스타트 화면 (고객 메뉴, 그룹 메뉴, 조회 메뉴)를 선택하도록 입력 유도 문이 출력되며, 해당 메뉴를 선택하면 메뉴 값이 리턴되어 selectMenu메서드가 switch 문으로 해당 메뉴의 showmenu를 호출하도록 구현했습니다.

CustomerMenu 클래스는 Customers에 객체를 저장하기 전에, 해당 객체를 생성하고 검증하고 , 수정/삭제를 한다면 해당 아이디가 존재하는지, 그리고 배열에 아무것도 들어있지 않아서 Null예외가 발생할 수는 없을지.. 정도의 역할을 부여했습니다.

Customer객체는 생성이 되면 바로 static 변수인 count가 생성자가 호출될 때 ++되도록 되어있기 때문에, 데이터 검증을 해당 메뉴에서 진행하도록 설계했습니다.

GroupMenu 클래스는 단순 그룹의 기준을 초기화, 수정, 조회하기 전에 원하는 그룹의 이름을 받아내고, 초기화가 되어있는지 확인이 된다면 수정/조회를 할 수 있도록 해 나름의 예외처리를 진행했습니다.

SummaryMenu 클래스는 말 그대로 요악 메뉴 이기 때문에, 해당 메뉴가 직접적으로 수행할 것은 출력 정도만 있도록 역할을 부여했습니다. classifiedCustomers 클래스에서 리스트를 가져와 단순히 내림차순/오름차순 정도만 고르도록 했습니다.

고민되었던 문제...🫠

• CustomerMenu 의 역할을 어떻게 지정해야 할지 고민이 되었습니다. MVC패턴으로 치자면 CustomerMenu 를 Controller 의 역할을 부여해야 할지.. 아니면 비즈니스 로직을 담당할 Model 의 역할을 부여해야 할지..
• 하지만 그정도로의 과한 디테일을 요구하는 설계가 필요한 작업은 아니라고 생각됐고, 해당 프로젝트가 장기 프로젝트가 아니고 어떠한 기능과 목표가 이미 정해진 프로젝트이기 때문에 단순설계로 끝내도록 했습니다.
  Customers가 주방이라고 치자면 그 전을 담당하는 카운터 정도의 역할을 부여하도록 했습니다.

고려했던 부분 😪

• 최대한 객체지향의 개념을 살려 어떠한 객체가 무엇을 갖고 어떠한 작업을 진행합니다. 의 내용을 갖고있도록 메소드를 선언했습니다.

Customers가 고객 고유번호로 삭제를 합니다.(주어지는 값은 고유번호)

• 메소드의 이름을 최대한 해당 메소드가 담당하는 역할을 명시하도록 작성해주었습니다.
  

  

GroupMenu 가 Parameter를 만든다. / 입력값을 토대로 그룹의 인덱스를 가져온다.

• 객체가 하나로만 생성되어 관리가 될 필요가 있는 객체들은 싱글톤으로 관리하고, 객체주입을 많이 활용했습니다.

스프링 개념에 자주 등장하던 의존성 주입에 대한 활용을 자바에서 연습해볼 수 있도록 진행했습니다.

아쉬웠던 점과 좋았던 점 ⭕️❌

아쉬웠던 점❌

• 이번 토이프로젝트를 진행하면서, 기존에 다른 토이프로젝트를 진행해왔을때 깃 사용에 대한 아쉬움이 항상 있었어서 다음 토이프로젝트는 시작부터 깃으로 관리를 꾸준히 해가면서 진행해야겠다.. 하는 생각이 있었지만 실패했습니다.(?) 급한 성격이 문제인듯 합니다..... 다음엔 꼭 이러지 않도록 노력해야겠습니다.
• 예외처리에 대한 기본적인 지식이 부족했습니다. 처음에 뭣모르고 예외관리 클래스를 만들어 모든 예외에 대한 정의를 마치 프린트문 출력하듯이 메소드를 선언했고, 아는 지인에게 피드백을 받고 찾아본결과,
  예외를 직접 생성하면 단순히 생성만으로 많은 자원을 이용하게 되고, 이것과 마찬가지로 throw를 많이할수록 또한 메모리 낭비가 심해진다는걸 알게되었습니다. 이부분에 대한 공부를 더 할 예정입니다.

좋았던 점⭕️

• 진행하면서 개인적으로 애매모호했던 스프링의 역전제어와 의존성주입, 그리고 빈이 스프링에서 어떠한 역할을 하는지 이해가 더 잘된 느낌입니다. 스프링을 들어가기 전에 이런 토이프로젝트를 진행하고 들어갔으면 얼마나 좋았을까 라는 생각도 들지만, 강사님의 프로젝트 구성이 정말 알차다고 느껴졌습니다. 우리 국비 기수 복받았다..!
• 클래스 설계를 거의 처음으로 진행해보고 하나부터 열까지 신경쓰려고 했던 첫 프로젝트였고, 성공적이었던것 같습니다. 객체지향이 무엇인지 단순히 말로 설명하기는 어렵고, 그걸 이해하기도 어렵지만, 이번에 확실히 개념을 챙겨가는 느낌입니다.
• 코드가 더 깔끔해진것 같습니다. 강사님께서 강의에서 알려주신 내용을 바탕으로 더 깔끔한 메소드를 작성하려고 노력했고 그 결과 가독성이 좋고 해당 부분이 어떤 재료를 가지고 어떠한 행동을 하는지 표기할 수 있게 되었습니다.
• 성능에 대한 고민을 할 수 있는 시간이었습니다. 그룹핑이라는건 어떠한 목록을 탐색해서 짚어내는 행동이기도 한데, 그에 따른 생각을 많이 해볼 수 있는 시간이었습니다.

시연 화면

마무리

글이 굉장히 길지만, 제가 공부를 시작한 이후로 나름 기록을 남길 수 있는 첫 토이 프로젝트라고 생각해 기록을 남기게 되었습니다.

9월 초, 제가 처음으로 자바를 시작했었을 때 JDBC API를 이용해 게시판 프로그램을 만든 적이 있었습니다.

그때의 설계와 지금의 설계는 정말 말로 설명할 수 없을 정도로 다릅니다.

공부라는 건 항상 내가 잘하고 있는지 많이 힘들 수밖에 없는 부분인데.. 이에대한 체크를 하려면 보통 과거의 나와 비교를 하는 수 밖에 없다고 생각합니다.

이번 토이 프로젝트로 인해서 내가 정말 잘하고 있구나.. 굉장히 많이 늘었구나.. 나 나름 똑똑하구나..(?)라는 생각을 갖게 되었고 공부가 더 재밌어진 것 같습니다.

물론 해야 할게 많지만 멀리 본다면 제가 배워야 할 것들이 넘어야 할 산들이 아니라 오히려 더 겪어볼 수 있는 어떠한 놀이가 될 수 있겠다는 생각에 설레는 것 같습니다.