스프링 (7) 썸네일형 리스트형 MVC 서블릿-> 서버코드에서 자바로 html만드는 것 하지만 매우 복잡하고 비효율적 jsp->html에서 자바코드 쓰는거 ->이것도 비효율적 =>mvc등장 비즈니스 로직은 서블릿 처럼 다른 곳에서 처리하고 jsp는 목적에 맞게 html로 화면을 그리는 일에 집중하자! 역할을 나눠서! 번경할 때 편하게! 기능 특화로! 컨트롤러: HTTP 요청을 받아서 파라미터를 검증하고, 비즈니스 로직을 실행한다. 그리고 뷰에 전달할 결과 데이터를 조회해서 모델에 담는다. 모델: 뷰에 출력할 데이터를 담아둔다. 뷰가 필요한 데이터를 모두 모델에 담아서 전달해주는 덕분에 뷰는 비즈니스 로직이나 데이터 접근을 몰라도 되고, 화면을 렌더링 하는 일에 집중할 수 있다. 뷰: 모델에 담겨있는 데이터를 사용해서 화면을 그리는 일에 집중한.. 빈 생명주기 콜백 그냥 생성자를 호출하면 객체생성->의존관계가 되어버림 우리가 원하는 순서는 1.스프링 컨테이너 생성 2.스프링 빈 생성 3.의존관계 주입 4.초기화 콜백 5.사용 6.소멸전 콜백 7.스프링 종료 @PostConstruct(4) @PreDestroy(6) 사용으로 해결! 의존관계 자동 주입 1. 생성자 주입 생성자 호출 시점에 딱 한번 호출되는 것 보장 불변, 필수 의존관계에 사용 생성자가 한개만 있으면 @Autowired 생략 가능(스프링 빈에서만) 2. 수정자 주입 setter라 불리는 필드의 값을 변경하는 수정자 매서드를 통해서 의존관계 주입하는 방법 선택, 변경 가능성이 있는 의존관계에 사용 3. 필드 주입 코드가 간결해서 많은 개발자를 유혹하지만 외부에서 변경이 불가능 해서 테스트하기 힘들다 DI프레임워크가 없으면 아무것도 할수 없다 ->사용하지 말자 4. 일반 메서드 주입 한번에 여러 필드를 주입받을 수 있다 일반적으로 잘 사용하지 않는다 -----> 생성자 주입을 선택해라!!! why? 불변! 대부분의 의존관계 주입은 한번 일어나면 애플리케이션 종료시점까지 의존관계를 변경할 일.. 싱글톤 싱글톤 패턴 클래스의 인스턴스가 딱 1개만 생성하는 것을 보장하는 디자인 패턴 ->스프링 쓰면 자동적으로 만들어줌 private생성자를 사용해서 외부에서 new키워드 못쓰게 막아야해 (getInstance()만들어서 함) 단점 - 싱글톤 패턴을 구현하는 코드 자체가 많이 들어간다. - 의존관계상 클라이언트가 구체 클래스에 의존한다->DIP 위반 - 클라이언트가 구체 클래스에 의존해서 ocp 원칙을 위반할 가능성이 높다 -테스트하기 어렵다 -내부속성을 변경하거나 초기화 하기 어렵다 -private 생성자로 자식 클래스를 만들기 어렵다 -결론적으로 유연성이 떨어진다 -안티패턴으로 불리기도 한다 싱글톤 컨테이너 싱글톤 패턴의 문제점을 해결하면서, 객체 인스턴스를 싱글톤으로 관리 ->스프링 빈 싱글톤 방식을 사.. IoC(제어의 역전) Inversion of Control -기존 프로그램은 클라이언트 구현 객체가 스스로 필요한 서버 구현 객체를 생성하고, 연결하고, 실행했다. 한마디로 구현 객체가 프로그램의 제어 흐름을 스스로 조종했다. 개발자 입장에서는 자연스러운 흐름이다. -반면에 AppConfig가 등장한 이후에 구현 객체는 자신의 로직을 실행하는 역할만 담당한다. 프로그램의 제어 흐름은 이제 AppConfig가 가져간다. -프로그램에 대한 제어 흐름에 대한 권한의 모두 AppConfig가 가지고 있다. -프로그램의 제어 흐름을 직접 제어하는 것이 아니라 외부에서 관리하는 것을 제어의 역전이라 한다. config AppConfig - 애플리케이션의 전체 동작방식을 구성(config)하기 위해, 구현 객체를 생성하고, 연결하는 책임을 가지는 별도의 설정클래스를 만들자 구현체 입장에서는 어떤 구현객체가 들어올지 알수 없다 appconfig에서 결정 구현체는 의존관계에 대한 고민은 외부에 맡기고 실행에만 집중 appConfig만 바꿔주면 돼 다형성ㅇ으로 새로운 거 추가개발하는거 문제 없어 -구성정보에서 역할과 구현을 명확하게 분리 -역할이 잘 들어남 -중복제거 SRP(단일 책임 원칙) -> 구현 객체를 생성하고 연겨하는 책임은 AppConfig가 담당 DIP(의존관계 역전 원칙) -> 클라이언트 코드가 추상화 인터페이스에만 의존하도록 OCP(개방폐쇄 원칙) -> 다형성 사용하고 클라이언트가 DIP지킴, 소소프트웨어 요.. 객체 지향 특징 추상화 캡슐화 상속 다형성 - 역할과 구현으로 세상을 구분 역할(인터페이스) 구현(객체, 클래스) 클라이언트의 영향을 미치지 않고 기능을 바꿀 수 있다 클라이언트는 역할만 알만 된다 클라이언트는 구현, 내부구조 몰라도 클라이언트는 구현 변경되도 클라이언트는 대상자체변경해도 돼 - 인터페이스를 구현한 객체 인스턴스를 실행 시점에 유연하게 변경할 수 있다. 다형성의 본질을 이해하려면 협력이라는 객체 사이의 관계에서 시작해야함 클라이언트를 변경하지 않고, 서버의 구현 기능을 유연하게 변경할 수 있다 -인터페이스를 잘 구현하는게 중요!! 객체들의 모임 객체는 메세지를 주고받고 데이터를 처리할 수 있다 -> 프로그램을 유연하고 변경이 용이하게 만듦 나중에 알아볼것 loC(제어의 역전),DI(의존관계 주입) 이전 1 다음
