테크 시그널

Front Controller Pattern: 프론트 컨트롤러에서 전처리, 후처리함으로써 뒤의 컨트롤러들이 할 필요없음 근데 그 컨트롤러-> 뒷단의 컨트롤러 바로 호출하면 결합력이 생겨버려 프론트컨트롤러가 계속 변하게됨 그래서 Command Pattern 적용, HandlerMApper, HAndlerInvoker 생기고 뒤의 컨트롤러들은 POJO(Plain Old Java Object)가 됨 CharEncodingFilter FrontController FileUPloadRequestWrapper HMapper, HInvoker 의 똑같은 일을 하는 놈들을 스프링에서 제공합니다 ckEditor에서 사진 올리려면 URL 을 사용할 수 있도록 web Resource가 필요하게된다. 근데 이 설정을 >내가 ..

- 필터 체인 통과 -> FileUploadRequestWrapper덕에 원본 요청이 바뀜. -> PartWrapper로 파트 나누고 wrapping -> Front Controller에서는 req가 FileUploadRequestWrapper 가 되어 들어옴. 그안에는 partWrapperMap이 들어있음 -> HandlerInvoker -> FileUploadController - FileUploadCheckFilter: Request header에서 MIME에 multipart가 있는지 체크하는 필터. - 파라미터 대신 multipart로 되어있으면 part API 써야하는데 얘 어려우니 Part Wrapper를 쓰자. CommandHandler 만들 때 중요한 점 1. 필요한건 invoker로부터..

순서: Authentication -> Authorization 인가 처리, 인증 처리를 해서 접근 제어를 해줘야한다. 의도적으로 주소를 입력해 접속하는 것도 제어해야함. => 모든 요청에 대해 보안 처리를 하려면 Front Controller 앞에서 해줘야함. D.F.P(Decorating Filter Pattern) 을 사용한다. - Decorating 패턴 : 비즈니스 로직은 아니지만 부가적으로 추가하고 싶을 때 사용 - Filter: HTTP 요청과 응답을 변경할 수 있는 재사용 가능한 객체 변경? 원본에서 Wrapper 로 감싸진다. - 용도: 사용자 인증이나 권한 체크, request의 전처리와 response의 후처리를 담당하는 역할함 Filter Chain: 필터가 여러개일 때 Filter..

www.notion.so/techsignal/resolver-a0d7c594c3d74a79941a4d6113887490 여러분 그거 아시나요? 웹으로 접속하셔서 링크에 커서를 갖다대면 무슨 일이 일어나는지???!?!?!!? resolver Resolvers: www.notion.so 클릭 클릭! ReqParam 어노테이션을 사용하면 해당 컨트롤러 코드 내에서 req.getParameter()를 할 필요가 없어진다. T 타입 사용하기 상세검색을 하고 싶은데 어떤 타입으로 지정해야할지 모르겠다??? 1. 일단 PagingVO에선 T타입으로 선언해둔다 2. 그 안에 들어갈 변수가 뭐뭐 있는지 봄 3. prod_lgu, prod_buyer, prod_name... ProdVO의 변수들이다?! ->컨트롤러에서 P..

public int createProd(ProdVO prod); Service에서 리턴타입을 int로 하면 식별성 없음. (dao에선 가공을 못하므로 int로 할 수 밖에 없음) insert, update할 때 null허용일 때는 JDBCType 꼭~! DATE -> jdbcType=DATE CLOB -> jdbcType=VARCHAR NUMBER -> jdbcType=NUMERIC 컨트롤러에서 항상 반복되는 코드들 처음에 req.setCharacterEncoding("UTF-8"); 마지막에 req.getRequestDispatcher(goPage).forward(req, resp); Front Controller 들이 할 일 - 각 커맨드(URI에 연결되어있음)를 처리할 수 있는 백엔드 컨트롤러 목록..

오늘의 포스팅은 라이브러리 설치 및 응용 위주입니다~! SLF4J (Simple Logging Facade For Java)를 써봅시다 1. 일단 먼저 설치! 2. Pom.xml에 dependency 추가하고 만약 Log4j, SLF4j 2개라면 commons-logging에서는 exclude Maven artifact하기. Log4j, SLF4j 각각 하나씩 해서 리모컨(파사드) 2개 근데 둘 중 하나만 써야됨. 3. log4j2.xml 이라는 이름의 파일을 만들어 SLF4j 설정 - Appender: 어디에 출력할건지 (콘솔인지, 파일 내부인지 등등) 1. 인덱스 필요 2. 통계 필요 => JDBC appender를 사용해 log를 DB에 등록 가능 - Layout: 어떤 포맷? - Logger **..

Java: OOPL DB: RDBMS 데이터를 표현하는 방식이 다름 객체 튜플, 릴레이션 프레임워크의 사용방법에 집중하기보다 동작구조의 원리를 보아야함 프레임워크: 미리 짜놓은 코드의 집합 =>프레임워크: IoC(Inversion of Control)됨, DI(Dependency Injection)패턴을 따르게 됨. Control권한이 역전되어 이제 개발자는 프레임워크를 따라야함 프레임워크와 라이브러리의 차이: Control이 inversion됐냐 안됐냐. e.g. common-lang3(라이브러리) 쓸때 우리는 우리 맘대로 했는데 iBatis의 구조는 개발자가 따라야만 함. 1. SQLMapper로서의 역할 - 커넥션과 쿼리객체를 대신 생성. (ibatis: #인라인파라미터# 를 pstmt의 ?로 바꾼..

등록할때 검증할 데이터, 수정할때 검증할 데이터 서로 다를 수도 있음 e.g. 주민번호의 경우 등록만 가능, 수정 불가 => 그러면 business logic이 다르고 적용할 validation도 달라져야함 Marker Interface(메서드가없는 인터페이스): 마킹해주는 것. 그냥 얘가 이런애다~하고 표현해줌 e.g. serializable(Ctrl+Shift+T로 확인하쇼), payload '인서트그룹이라는 힌트'가 적용되있는 경우에만 검증하겠다! 제약조건 여러개가 모여 하나를 이루게 하기 docs.jboss.org/hibernate/stable/validator/reference/en-US/html_single/#section-constraint-composition Hibernate Valida..

layered architecture Architecture Diagram 손님 들어옴 -> 웨이터 만남(컨트롤러) -> 주문 (요청 받아 요청 분석) -> 셰프에게 전달(로직을 갖고있는 객체, business logic Object=service) => Persistence layer가 db에서 raw data 가져옴(=dao) => service가 가공 => controller(웨이터)가 받음 -> VO로 통에 담음 (=DTO, java bean )-> controller한테 돌려줌 -> 컨트롤러가 받아서 view로 보냄 -> view에서 예쁘게 꾸밈 (UI 구성) -> 손님한테 감 => 전달 구조 (각 layer로 나눠져있음) raw data 가져올떄 그걸 담을 통:VO dao는 순수하게 데이터만 ..

하면 jsp 2개가 합쳐져(include) 나타남. = 모듈화 모듈화 : 책임이 쪼개져있는 구조 장점: 유지보수 비용 감소 버퍼의 동작 순서가 다르다? 이동을 하는 과정에서 버퍼를 방출하냐/안 하냐 flush 하는순간 응답 데이터 나감. 한번이라도 방출하면 그 이후엔 에러가 발생해도 에러메시지 내보낼 수 없음 * include로 페이지 모듈화할때 한번쯤 버퍼가 방출됨. 근데 그러면 그 에러를 클라이언트한테 전달할 수 없음 (이미 상태코드가 200으로 나가서) 모듈화 해야할 땐 페이지 방출되는 상황 / 버퍼 제어할 방법 고려해야함. VO(Value Object), DTO(Data Transfer Object), Model(MVO패턴) - VO, DTO- 값을 가질 수 있고, 직렬화가 가능해야함 - Mode..