디그다의 개발

관리자와 직원 사이에 양방향 통신을 할 일이 존재했고 polling 방식과 websocket 방식 사이에 선택을 해야하는 것이 필요했습니다. 하지만 다음과 같은 이유로 웹소켓을 통해 양방향 통신을 제공했습니다. 1. 관리자 - 직원 간의 통신하는데 있어 실시간 통신이 필요했다. 2. polling 방식을 통해서 구현시 데이터 조회시에 select 절의 사용이 꽤나 큰 비용이였다. (웹소켓은 패킷 데이터에 대한 내용을 db에 insert 하기만 하면 됐고, 이전 문의 내역이나 공지사항 같은 내용은 초기 연결 시에 db에서 select 하게 되므로 그 후의 내용들은 select 가 발생하지 않는다.) 3. polling 은 매번 커넥션을 맺는 비용이 드는 반면 웹소켓의 경우 매번 커넥션을 맺지 않고 유지를 ..

프로젝트 진행 도중 excel 파일에 대해 요청을 받고 그 엑셀 파일을 객체에 매핑시켜주는 기능을 작성해야하는 일이 생겼습니다. 아파치 에서 제공하는 excel xml 파서기인 아파치 poi 를 통해 해당 기능을 작성해보겠습니다. 다음과 같이 엑셀 파일이 존재할 경우 다음 객체에 매핑을 시켜줄 것입니다. 엑셀 파일을 처리하는 결과 값으로는 ExcelDAO 의 List 형태로 반납하게 됩니다. 또한 Reflection 과 제네릭을 활용하여 단순하게 하나의 객체에만 매핑하는 것이 아닌 다른 객체에도 매핑이 되게끔 만들어 보겠습니다. 사전지식을 알아가보겠습니다. 리플렉션 이란? 리플렉션은 힙 영역에 로드된 Class 타입의 객체를 통해, 원하는 클래스의 인스턴스를 생성할 수 있도록 지원하고, 인스턴스의 필드와..

파이썬을 통해 검사결과 양식을 받아서 spring 서버에서 처리하는 도중 검사 결과 1건당 15~20 여개의 insert query 가 발생했습니다 당연하게도 검사 파일은 수십만건이므로 insert query 또한 수백만 건이 발생하게 됩니다. 따라서 insert 에 대해 단건 insert 가 수백만 개가 예상되어 상당한 성능 저하가 예상이 되었고 이를 batch insert 로 해결해 보겠습니다. batch insert 로 처리를 계획한 이후 당연하게도 jpa 의 영속성 컨텍스트와 관련하여 키생성 전략과 맞물려 이슈가 발생하였고 이를 해결하는 과정을 포스팅 해보겠습니다. 알아볼 내용은 다음과 같습니다. 1. 영속성 컨텍스트의 Entity 저장 전략 2. 각 키생성 전략의 Id 초기화 방식 3. spri..

프로젝트 진행 와중 선착순으로 설명회를 신청할 때 동시성을 고려해야 하는 상황이 발생했고 이를 각각 낙관적 락과 비관적 락으로 해결해보는 과정을 보이려고 합니다. 먼저 프로젝트의 도메인을 간략하게 살펴 보도록 하겠습니다. 학부모는 설명회를 신청하고, 신청인원이 마감되어 있다면 대기 신청을 진행하게 됩니다. 따라서 각각 설명회(Presentation), 신청(Participation), 대기(Waiting) 의 도메인에 대한 설명을 해보겠습니다. 설명회 도메인 @Entity @NoArgsConstructor @Getter public class Presentation { @Id @GeneratedValue private Long id; private String name; private Integer ma..

기존 프로젝트의 요구 사항이 바뀌어 짐에 따라서 이미지를 저장하는 정책이 변경되는 이슈가 발생했습니다. 프로젝트에는 이미지를 저장, 변경하는 도메인들이 존재했고 프로필 이미지를 업데이트 하거나, 정보에 관련된 이미지를 업데이트 하는 서비스를 제공 중 이였습니다 따라서 추가로 발생할지 모르는 정책변경과 기존 정책의 활용 가능성으로 인해 imageService를 인터페이스로 공통화 하고 이미지를 사용하는 domain들을 공통 처리를 하는 과정을 작성해 보겠습니다. 저의 목표는 다음과 같습니다. 1. 이미지 사용 도메인들을 다형성을 사용하여 공통화 Q) 제네릭을 사용하면 안되는 가? A) imageService를 bean에 올려놓고 사용할 것이기 때문에 이는 불가 합니다. 추가적으로 이미지 서비스를 사용하지 ..

https://digda.tistory.com/38 [Spring Security + AOP] 로그를 찍어보자 - 로그인 인증 (1) https://digda.tistory.com/36 Spring Security 흐름 Spring Security Stream 스프링 시큐리티의 제일 중요한 포인트는 인증(Authentication) 과 허가 (Authorization)이다. 인증 - '누구인지 증명하는 과정' 인가(허가) - '권한 digda.tistory.com 해당 예제의 github : https://github.com/digda5624/spring_security_study GitHub - digda5624/spring_security_study: 서버 로깅 작업을 위한 스프링 시큐리티 예제 + ..

https://digda.tistory.com/36 Spring Security 흐름 Spring Security Stream 스프링 시큐리티의 제일 중요한 포인트는 인증(Authentication) 과 허가 (Authorization)이다. 인증 - '누구인지 증명하는 과정' 인가(허가) - '권한이 있는지 확인하는 과정' 모든 HTTP.. digda.tistory.com 해당 예제의 github : https://github.com/digda5624/spring_security_study GitHub - digda5624/spring_security_study: 서버 로깅 작업을 위한 스프링 시큐리티 예제 + 로깅 시스템 개발 서버 로깅 작업을 위한 스프링 시큐리티 예제 + 로깅 시스템 개발. Con..

SOLID SRP : 단일 책임 원칙 OCP : 개방 - 폐쇄 원칙 LSP : 리스코프 치환 원칙 ISP : 인터페이스 분리 원칙 DIP : 의존관계 역전 원칙 SRP 하나의 클래스는 하나의 책임만을 가져야 한다. 하나의 책임이라는 것은 모호하다 클 수 있고, 작을 수 있다. 문맥과 상황에 따라 다르다. 그렇다면 책임이라는 기준이 뭘까? 중요한 기준은 "변경" => 변경이 있을 때 파급 효과가 많다면 잘 따르지 못한 것이다. OCP 소프트웨어 요소는 확장에는 열려 있으나 변경에는 닫혀 있다. => 인터페이스는 변경을 하지 않고 구현 클래스를 만드는 것은 OCP 원칙을 잘 지킨 것이라고 볼 수 있다. 하지만 개발의 특성상 OCP 원칙을 지키는 것은 정말 어려운 일이다. 예를 들어 보자 만약 MemberSe..