흰 스타렉스에서 내가 내리지

모듈화 예를들어 어떤 컨트롤러가 여러개의 리포지터리를 사용하여 데이터를 조회한후 가공하여 리턴한다고 가정해 보자. 이러한 기능을 서비스로 만들어 두면 컨트롤러에서는 해당 서비스를 호출하여 사용하면 된다. 하지만 서비스로 만들지 않고 컨트롤러에서 구현하려 한다면 해당 기능을 필요로 하는 모든 컨트롤러가 동일한 기능을 중복으로 구현해야 한다. 이러한 이유로 서비스는 모듈화를 위해서 필요하다. 보안 컨트롤러는 리포지터리 없이 서비스를 통해서만 데이터베이스에 접근하도록 구현하는 것이 보안상 안전하다. 이렇게 하면 어떤 해커가 해킹을 통해 컨트롤러를 제어할 수 있게 되더라도 리포지터리에 직접 접근할 수는 없게 된다. 엔티티 객체와 DTO 객체의 변환 Question, Answer 클래스는 엔티티(Entity) 클..

BeanFactory와 ApplicationContext BeanFactory 스프링 컨테이너의 최상위 인터페이스다. 스프링 빈을 관리하고 조회하는 역할을 담당한다. getBean() 을 제공한다. 지금까지 우리가 사용했던 대부분의 기능은 BeanFactory가 제공하는 기능이다. ApplicationContext BeanFactory 기능을 모두 상속받아서 제공한다. 빈을 관리하고 검색하는 기능을 BeanFactory가 제공해주는데, 그러면 둘의 차이가 뭘까? 애플리케이션을 개발할 때는 빈을 관리하고 조회하는 기능은 물론이고, 수 많은 부가기능이 필요하다. ApplicatonContext가 제공하는 부가기능 메시지소스를 활용한 국제화 기능 - 예를 들어서 한국에서 들어오면 한국어로, 영어권에서 들어오면..

컨테이너에 등록된 모든 빈 조회 import ... public class ApplicationContextInfoTest { AnnotationConfigApplicationContext ac = new AnnotationConfigApplicationContext(AppConfig.class); @Test @DisplayName("모든 빈 출력하기") void findAllBean(){ String[] beanDefinitionNames = ac.getBeanDefinitionNames(); for (String beanDefinitionName : beanDefinitionNames){ Object bean = ac.getBean(beanDefinitionName); System.out.printl..

강의1. 주문, 주문상품 엔티티 개발 @Entity @Table(name = "orders") @Getter @Setter public class Order { ... ... ... //==생성 메서드==// public static Order createOrder(Member member, Delivery delivery, OrderItem... orderItems) { Order order = new Order(); order.setMember(member); order.setDelivery(delivery); for (OrderItem orderItem : orderItems) { order.addOrderItem(orderItem); } order.setStatus(OrderStatus.ORDER..

강의1. 상품 엔티티 개발 (비즈니스 로직 추가) 객체지향적으로 생각해봤을 때, 데이터를 가지고 있는 쪽에 비즈니스 메서드를 작성하는게 좋다. (서비스 측이 아닌) 그래야 응집력이 있다. setter를 통해 바깥에서 계산해서 넣는 것이 아니라, stockQuantity를 내부에서 처리하는 비즈니스 메서드를 만들어라. 45번 줄에 보면 커스텀으로 exception을 만들었다. 강의2. 상품 리포지토리 개발 16번줄: item은 JPA에 저장할 때 까지 id 값이 없다. id 값이 없다는건 새로 생성한 객체라는 뜻이므로 em.persist()를 통해 신규 등록한다. 18번줄 : else 이면 이미 db에 등록된 것이므로 update 비슷하게 한거라 생각하면 된다. 강의3. 상품 서비스 개발 상품 서비스는 상..

SRP (Single Responsibility Principle) : 단일 책임 원칙 OCP (Open/Closed Principle) : 개방-폐쇄 원칙 LSP (Liskov Substitution Principle) : 리스코프 치환 원칙 ISP (Interface Segregation Principle) : 인터페이스 분리 원칙 DIP (Dependency Inversion Principle) : 의존관계 역전 원칙 1. SRP - Single Responsibility Principle 한 클래스는 하나의 책임만 가져야 한다. 중요한 기준은 변경이다. 변경이 있을 때 파급효과가 적으면 단일책임원칙을 잘 따른 것 예) UI변경, 객체의 생성과 사용을 분리 2. OCP - Open/Closed Pr..

PK : Primary key, 중복이나 빈값(NULL)이 들어올 수 없음 NN : Not Null UQ : Unique, 중복 값을 넣을 수 없음 B : Binary, 데이터를 이진 문자열로 저장함 (ex 이미지 파일) UN : Unsigned ZF : Zero Filled, 크기보다 작은 값을 넣었을 경우 0으로 채운 뒤 삽입시킴 AI : Auto Increment, Insert 시마다 값 1씩 늘어남 G - 다른 열을 기반으로 한 수식으로 생성된 값 Default/Expression - 기본값, 기본값에 수식 설정

naver_db 라는 이름의 database 생성 CREATE DATABASE naver_db; member 테이블 생성 USE naver_db; DROP TABLE IF EXISTS member; CREATE TABLE member ( mem_idCHAR(8) NOT NULL PRIMARY KEY, mem_nameVARCHAR(10) NOT NULL, mem_numberTINYINT NOT NULL, addrCHAR(2) NOT NULL, phone1CHAR(3) NULL, phone2CHAR(8) NULL, heightTINYINT UNSIGNED NULL, debut_date DATE NULL ); buy 테이블 생성 DROP TABLE IF EXISTS buy; CREATE TABLE buy ( ..

동적SQL : 미리 SQL을 준비한 후에 나중에 실행하는 것. PREPARE : SQL 문을 실행하지는 않고 미리 준비만 해놓는다. EXECUTE : 준비한 SQL 문을 실행한다. DEALLOCATE PREPARE : 준비한 SQL문을 해제한다. 예제 동적 SQL의 활용 PREPARE 문에서는 ?로 입력될 값을 비워 놓고, 나중에 USING으로 값을 전달할 수 있다. 예제

Stored Procedure DELIMITER $$ CREATE PROCEDURE 프로시저_이름() BEGIN -- 이 부분에 SQL 프로그래밍 코딩 END $$ -- stored procedure 종료 DELIMITER ; -- 종료 문자를 다시 세미콜론으로 변경 CALL 프로시저_이름(); -- stored procedure 실행 DELIMITER $$ : 세미콜론(;)으로는 SQL의 끝인지, stored procedure의 끝인지 구별할 수 없어서 $$를 사용한다. IF 문 IF THEN ... END IF; 사용 예시 DROP PROCEDURE IF EXISTS ifProc1; DELIMITER $$ CREATE PROCEDURE ifProc1() BEGIN IF (100 = 100) THEN ..