[논의] 파일 관리 기능 구현 설계 및 적용 방안

[SeoGyeongWon]

파일 기능 관리 #19

파일 관리 기능은 데이터 백업 관리 기능의 csv, log 파일 저장 및 직원 관리 기능의 이미지 저장 + 이미지 다운로드 기능(페이지에 사진이 나올 수 있도록 보여주는것이 다운로드)이 있습니다.

파일 관리 기능은 파일의 실제 파일과 파일의 메타정보 파일로 분리되서 관리되어야 합니다.

• 실제 파일은 따로 디렉토리에서 저장될 수 있도록 구현

• 메타정보는 엔티티로 하여, 디비에 저장하여 관리

앞서, 파일 관리 기능에 작성되고 있는 내용들을 간략하게 설명드리겠습니다.

메타 정보

메타 정보의 엔티티는 파일 Id, 파일명, 파일 형식, 파일 크기, 파일 경로로 구성하였습니다.

• 파일 경로를 두어 실제 파일의 byte[ ] 정보를 디비에 두지 않고 디렉토리에 저장된 파일의 위치를 구하기 위함입니다.
• MultipartFile을 컨트롤러 측에서 호출하여 서비스에서 MultipartFile에 대한 실제 파일을 저장하고 실제 파일저장이 성공하면 메타 정보를 저장할 수 있도록 합니다.

실제 파일

사용자 디렉토리에 파일을 저장하는 폴더를 두고, 그 밑에 하위 디렉토리(csv, log, image)를 두어 각 MIME 타입에 맞게 파일이 저장될 수 있도록 합니다.

DTO

DTO는 파일의 메타정보를 반환하는 FileMetaDataDto와 파일 다운로드 시 파일을 전달하기 위한 FileDownloadResponseDto를 두었습니다.

FileMetaDataDto

• 파일 Id, 파일명, 파일 형식, 파일 크기, 파일 경로 전달

FileDownloadResponseDto

• 파일 다운로드 시 파일의 Id를 전달하여 그 Id에 해당하는 실제 파일 값 전달
• fileId, byte[] fileData

Service

파일을 저장하는 기능, 파일을 다운로드 하는 기능을 구현합니다.

BasicFileService.class & FileService(Interface)

• public FileMetadataDto saveFile(MultipartFile multipartFile) { }
  • FileMetaDataDto를 반환타입으로 하여 메타 정보 저장하는 메서드
  • 실제 파일이 저장된 후 메타정보가 저장되도록 하고자 합니다.
  • MultipartFile에서 메타 정보만 저장하는 기능을 가지도록 합니다.
  • 메타정보 받아오는 방법으로 MultipartFile의 함수를 사용할려고 합니다.
  • MultipartFile의 함수
    • getOriginalFileName() : 파일명+파일 확장자명까지 합쳐진것 (ex_ photo.png 가 하나의 이름)
    • getContentType(): MIME 타입을 반환하여 "image/"와 "text/log" , "text/csv"를 반환하고자 함
    • getSize(): 파일의 크기 반환
• public FileDownloadResponseDto downloadFile(Long fileId) { }
  • FileDownloadResponseDto를 반환타입으로 하는 다운로드 기능을 실행하는 메서드
  • 파일 Id와 Id에 해당하는 파일 경로의 byte 값을 전달하여 실제 파일이 전달될 수 있도록 함

따로 FileUtil 클래스를 두어 디렉토리 생성및 설정을 담당하는 부분을 두었습니다.

FileUtil.class

• 기본 디렉토리('user.dir'의 file-data-map폴더)와 하위 디렉토리(image, csv, log) 생성
• 저장 파일명은 UUID와 파일아이디를 합쳐서 사용해 파일명이 중복되는것을 방지하고자 함
• 전체경로(기본디렉토리+하위디렉토리+저장 파일명)로 실제 파일을 저장

Controller

아직 기능 구현을 진행하지 않아 어떻게 진행할지 계획하지 않았습니다.

파일관리 컨트롤러는 GET 메서드만 사용합니다.(파일 다운로드 시 사용)

---

주요 Discussion

백업 관리 기능의 csv, log 파일 저장과 직원 관리 기능의 이미지 등록및 다운로드

직원 관리 기능

직원 관리 기능 부분에서 파일 관리 기능을 참조하기 위해서는 파일의 아이디를 키로써 참조하기에 따로 파일관리 측에서는 Employee Id를 받아오지 않아도 된다고 생각합니다.

employee측에서 이미지를 등록하는 부분에 있어서 EmployeeController 부분에서 이미지를 MultipartFile로 지정하여 BasicFileService를 호출해 등록하면 될것 같다고 생각합니다.

이미지등록이 성공하면 파일이 저장되고 메타 정보가 저장되면서 파일Id가 생깁니다. 그 파일 Id를 직원 관리 기능 부분에 반환하면 될것 같다고 생각합니다.

직원이 삭제되면 저장한 파일도 같이 삭제되어야 하는데 이부분을 어떻게 연결하면 좋을까하고 생각이 됩니다. 직원 엔티티에 저장된 프로필 Id값이 직원 정보와 함께 같이 사라지면 자동으로 파일 엔티티에 있는 Id값이 사라지도록 해야할것 같습니다.

백업 관리 기능

백업 관리 기능 부분에서 파일을 쓰고, 생성까지 진행하므로 백업 관리 기능 부분의 컨트롤러 부분에서 Multipart 형태로 변환하여 BasicFileService를 호출하여 저장이 진행되면 되지 않을까 하고 생각합니다.

[mainlib990]

@SeoGyeongWon 님 안녕하세요! 비지니스 로직 구현과 다른 모듈간 인터페이스 상호작용에 대한 내용 잘 읽었습니다.

다음은 파일 관리 서비스 구현에 대한 제 의견입니다:

• 파일 저장 위치:
  • 로컬 환경에서는 현재 사용자 디렉토리(Current Working Directory), 프러덕션 환경에서는 커스텀 가능한 경로로 해주시면 좋을것 같습니다. 즉, application.yaml 파일을 통해 제어 가능하도록 구현해주셔야합니다. 좀더 구체적으로 설명드리면 파일 서비스 모듈에 FileConfig 만드신다음에 파일 경로를 지정하는 Bean을 등록해주시면 좋을것 같습니다. 그리고 등록된 Bean을 통해 FileService에서 주입받는 형태로 구현해주시면 깔끔한 코드가 구현될걸로 예상됩니다.
• 메타 정보:
  • 다른 테이블과 조인하기 위해서는 Owner Type과 Owner Id를 알아야합니다. 예를들어 Employee 테이블과 조인하기 위해서는 해당 메타데이터가 있어야 조인이 가능합니다. 만약, 이 정보를 갖고 있지않게 된다면 조인 자체가 불가능합니다.
  • 현재 ERD 정의에 의하면 프로파일 이미지에 대한 ID가 Employee에 있지만 File로 옮겨가야 맞는 설계가 될것 같습니다. 데이터 백업도 마찬가지입니다. 데이터 백업 아이디가 File 테이블에 저장되야할것 같습니다.
  • 저희가 나눈 대화는 다형성 연관관계(Polymorphic Association)에 해당합니다. 한 번 찾아보시는것도 좋을 것 같습니다.

다음은 모듈간 인터페이스 상호 작용에 대한 제 의견입니다:

• EmployeeService에서 FileService를 호출할 상황은 다음과 같습니다:
  • 파일을 저장할때: EmployeeService에서 FileService.save(employeeId, profile) 이런 형태로 호출하려하려합니다. 그리고 반환 타입은 필요 없어보입니다. 인자 정보는 EmployeeId(Long Type)와 Profile(MultipartFile Type)을 그냥 넘기면 될걸로 예상 됩니다. 따라서 별도의 DTO는 필요 없어보입니다.
  • 파일을 삭제할때: EmployeeService에서 FileService.delete(profileId) 이런 형태로 호출하려합니다. 그리고 반환 타입은 필요 없어보입니다. 따라서 void 형태로 하시면 될것 같습니다. 또한, 인자 정보는 Long 타입으로 적절해보입니다.
  • 위 코드 예시는 예제입니다. 반드시 저런 메서드명을 갖을 필요는 없습니다. 또한, 상황에 맞게 디자인하시면 됩니다.

[mainlib990]

인터페이스 상호작용에 대한 추가 의견입니다.

save하고 profileImageId를 EmployeeService에서 반환하는걸로되어 있어서 save시 id 반환하는 형태로 디자인해주시면 될것 같습니다!

[mainlib990]

@chiho0270 님 의견 감사합니다! 만약 파일 엔티티 변경시 Backup Entity도 그렇게 변경하시면 될것 같습니다! 👍

[SeoGyeongWon]

@mainlib990 님 안녕하세요! 작성해주신 내용 잘 읽어 보았습니다.

작성해주신 Discussion중 메타정보에서 제가 이해한 내용이 맞는지 여쭤보고자 합니다.

직원 관리 파트의 프로필 이미지 아이디 백업 관리 파트의 백업 파일 아이디를 File엔티티에 넣는걸로 이해했습니다.

기존의 파일 아이디는 유지한채로 입니다.

따로 프로필 이미지 아이디와 백업 파일 아이디를 File 엔티티에 넣는 이유를 잘 모르겠습니다.

[mainlib990]

@SeoGyeongWon 님 좋은 질문입니다.

정규화 관점에서 한번 살펴볼게요. 만약 File에서 직원과 백업 아이디를 갖고 있지 않다는 말은 직원과 백업 모듈에서 파일 아이디를 가져야한다는 의미가 됩니다. 이 말은 두 엔티티에 컬럼이 추간된다는 의미가됩니다.

만약, File 모듈이 직원과 백업에 대한 아이디를 갖게 된다면 File Entity에만 컬럼이 존재하면 됩니다.
즉, 정규화 관점으로보면 File 엔티티에서 다른 엔티티를 참조하는 방식이 파일을 참조하는 필드를 줄일 수 있는 방법입니다.

[mainlib990]

좀더 구체적인 예시를 들어볼게요 만약 부서 모듈에서 부서 대표 이미지를 등록한다 생각해볼게요.

부서 엔티티에 파일 아이디를 참조하는 경우 필드가 추가되야 합니다.

파일 엔티티가 부서를 참조하는 경우 추가가 필요하지 않습니다.

이처럼 정규화시 파일 엔티티가 외래키를 가져야 합니다.

[mainlib990]

@SeoGyeongWon @chiho0270

정규화 비정규화 논의가 좀 필요해보입니다. 제쪽에서는 직원을 생성 완료하면 매번 프로파일 이미지의 아이디를 반환해야합니다. 이뿐만아니라 직원 조회시에도 프로파일 이미지의 아이디를 반환해야합니다. 따라서 프로파일 이미지의 아이디를 File 엔티티가 가질시 매번 요청해야하는 상황이 발생합니다.

이 문제를 해결하기 위해서는 profileImageId를 제 엔티티에 포함시켜야할것 같은데 다른 모듈들은 어떤 상황인지 궁금합니다.

[chiho0270]

아, 제가 말을 잘 못했던 것 같습니다.
우선 백업에서는 파일을 업로드 요청을 보내면 fileId를 반환 받는 식으로 파일 관리 측 @SeoGyeongWon 님께 요청했습니다.
이를 받아들이기로 해서 프로필 이미지를 생성하는 측에서도 같은 형태를 가지는 줄 알았습니다.

자세한 사항은 해당 디스커젼의 코멘트를 확인해주시면 될 것 같습니다.

• https://github.com/orgs/codeit-spring-6-part2-team2/discussions/42#discussioncomment-14778057

[mainlib990]

@chiho0270 님. Backup 모듈과 File 모듈간 인터페이스는 그렇게 해도됩니다. 일관성, 즉 리팩토링은 나중에 진행해도 상관 없습니다. 일단은 그대로 진행하셔도 되요! 지금 어느게 더 효과적인지 모르는 상황에서 Employee와 File간 인터페이스 규격으로 통일하실 필요 없습니다!

의도가 DTO간 인터페이스 규약 말씀하시는거 맞으시져??

[SeoGyeongWon]

프로파일 이미지의 아이디를 File 엔티티가 가질시 매번 요청해야하는 문제가 발생할것이라고 해주셨습니다.

LEFT OUTER JOIN으로 처리하면 어떨까 합니다.

파일 부분이 비어있어도 값이 출력이 되서 괜찮을것 같다고 생각합니다.