개요
-
Spring Quick Start 책 실습 정리입니다.
-
STS : Spring Tool Suite : 스프링을 쉽고 빠르게 이용할 수 있는 도구
-
유지보수가 중요- SW를 개발하고 유지보수하면서 정말 자주 발생함
-
요구정의, 분석, 설계 단계를 거치고 산출물이라는 설계도가 만들어짐
-
그 설계도에 기반해서 시스템을 만듬
-
시스템을 만든 사람하고, 유지보수하는 사람이 다름
-
-
보통 SI 인력들이 구축하고, SM 인력들이 유지보수함
- 자주 변경되기도 합니다.
-
작년까지는 고객 관리 시스템을 유지하다가, 인사 시스템을 유지하도록 업무가 변경될 수 있다.
-
항상
산출물이 정말로 중요합니다.- 자신의 느낌대로 유지보수를 하게 되면, 문제가 생깁니다.
-
시간이 지나면 지날수록, 아키텍처가 변경되고 틀어지기 때문
- 그래서 나온 해결책이 Framework
-
아키텍처를 이해하지 않고 프레임워크를 접근하는 것은 불가능합니다.
-
개발자들은 아키텍처를 건드릴 수 없고, 비즈니스 로직인 살만 건드릴 수 있음
-
아키텍처의 일관성,아키텍처의 통일!
프레임워크의 장점
-
설계에 들어가는 시간 단축 가능
-
쉬운 관리
-
개발자들의 역량 획일화
-
검증된 아키텍처의 재사용과 일관성 유지
자바 기반의 프레임워크
-
핵심은 Spring! / 대부분 오픈소스 형태로 제공된다.
-
우리 업계에서 최적화된 기능이 스프링에서 제공되지 않는 예
-
스프링을 커스터마이즈해서 활용하면 됩니다.
-
SI 회사들마다 자신들만의 자체 Framework를 확보하고 있음
-
-
정부 입장에서는, 업체를 바꾸는데 너무 힘듬
- 전자정부 표준 프레임워크를 만들어버린 것
-
모든 문제는 오픈소스를 그대로 써버리면 되는데, 자꾸만 변형되어 사용됨
-
표준만 지원하면 얼마나 좋아
-
자꾸만 뭔가를 추가해 ==> DBMS가 호환이 안되는 예시
-
-
SQL Mapper : SQL 구문을 Java 소스, xml이 되었든 작성해야 사용할 수 있음
-
ORM : SQL 명령어 조차도 프레임워크에서 제공해준다는 부분
3 Layer
-
Spring MVC가 Model 2 구조를 제공합니다.
-
Presentation : 화면
-
Business
-
Persistence : DB 연동
-
스프링도 여러 개의 Module로 구성되어 있다.
-
Spring은 여러가지 모듈로 구성(원하는 모듈만 선택적으로 받아 쓸 수 있다!)
-
지금은 Spring MVC로 평정이 되었음
-
IoC : Inversion Of Control / AOP : Aspect Oriented Perspective
-
- JPA
Spring Framework
-
EJB는 메모리를 엄청나게 잡아먹고 느림
-
EJB를 만들었다 해도, WAS가 없다면? TOMCAT에는 EJB 컨테이너가 없는 것처럼...
-
EJB를 대체하기 위한 기술로 Spring이 등장
Spring Framework 특징
LightWeight(경량)
POJO
-
클래스를 만드는 데 규칙이 없다(?), 규칙을 개발자가 직접 정의할 수 있다는 부분
-
Servlet, EJB가 POJO가 아님
-
Spring은 POJO를 기반으로 처리한다.
-
-
POJO는 부모가 없음 : 필요한 객체만 따로 받을 수 있음
-
pojo가 아닌 클래스는 너무 복잡합니다.
- 또한, pojo가 아니면 메모리를 많이 사용함
IoC
- Java 소스에서 new가 사라짐
AOP
- 정책을 바꾸기가 어려움
Container
-
Spring 자체가 컨테이너기능을 제공합니다.
-
특정 객체의 생성과 관리를 담당 & 객체 운용에 필요한 다양한 기능을 제공
-
xml 설정 파일을 로딩하는데 => xml 파일의 위치, 이름을 내 마음대로 servlet과 달리 결정할 수 있다.
- preloading을 기본으로 한다는 것
-
컨테이너가 구동되는 순간, 메모리에 많은 객체들이 올라옴
-
getBean("tv"): Dependency LookUp- 컨테이너 외부에서 client가 자신이 사용하고자 하는 객체를 container로부터 얻어내는 과정 : Dependency LookUp
-
IoC Container
- 결합도가 높은 프로그램 => 결합도가 낮은 프로그램으로 가자
-
src\main\resources 폴더를 추가해줍니다.
-
다형성만 추가하면 문제가 생김
-
TVUser가 100개 정도 있다면, 모두 찾아서 전부 수정해야 함
-
다형성을 적용하면 소스 수정의 범위를 줄일 수 있음
-
-
만약, 클라이언트 코드를 수정하고 싶지 않다면?
- 클라이언트를 전혀 수정하지 않고, Container 코드를 늘려주면 서비스가 가능하긴 하다
// Factory 디자인 패턴 적용
public class BeanContainer {
public Object getBean(String id) {
if(id.equals("lg")) {
return new LgTV();
}
if(id.equals("samsung")) {
return new SamsungTV();
}
if(id.equals("google")) {
return new GoogleTV();
}
return null;
}
}DL vs DI
-
Dependency Lookup : 컨테이너 외부에서 이루어지는 과정
-
Dependency Injection : 컨테이너 내부에서 이루어지는 IoC
DI의 3가지 형태
-
ex) 삼성 TV가 Sony Speaker에 의존적이라면?
- 의존적인 관계를 어떻게 Spring Container가 관리하는가
1. 생성자 Injection
- 거의 안 씀
2. Setter Injection
3. @Autowired를 이용한 Type Injection
context:component-scan을 이용
-
반드시 의존성 주입 대상 객체가 메모리에 있어야 한다.
-
의존성 주입 대상 객체는 반드시 유일해야 한다.
- bean vs @Component
-
bean : 유지보수 과정에서 변경되는 객체
-
@Component : 유지보수 과정에서 변경되지 않는 객체
-
내가 만들지 않은 클래스의 경우는 @(어노테이션)을 아예 사용할 수 없습니다.
- Bean 등록 밖에 답이 없음
-
Project > New > Source Folder: Eclipse 기준입니다.
<bean class="com.biz.board.BoardDAO"></bean>
<bean class="com.biz.board.BoardServiceImpl"></bean>
AOP - 바인드 변수
String method = jp.getSignature().getName(); // 이름
String method = jp.getSignature().toLongString(); // 메소드 시그니처
String method = jp.getSignature().toShortString();<bean id="dataSource" class="org.apache.commons.dbcp.BasicDataSource"
destroy-method="close"
>
<property name="driverClassName" value="org.h2.Driver" />
<property name="url" value="jdbc:h2:tcp://localhost/~/test" />
<property name="username" value="sa" />
<property name="password" value="" />
</bean>
<!-- JdbcTemplate -->
<bean class="org.springframework.jdbc.core.JdbcTemplate">
<property name="dataSource" ref="dataSource"></property>
</bean> <tx:advice id="txAdvice" transaction-manager="txManager">
<tx:attributes>
<tx:method name="*" rollback-for="Exception"/>
</tx:attributes>
</tx:advice>