[Chapter 3] Spring DI와 AOP 9강 ~ 17강

Mysql Workbench 사용법과 기초

 

스키마(SCHEMA)는 구조를 의미

 

수강신청 시스템, 쇼핑몰 시스템, 판매 시스템등 특정 시스템을 하나의 스키마로 부른다.

 

- Datatype

VARCHAR는 가변길이 문자열을 의미함

INT는 정수, DATE는 날짜 

 

- PK(Primary Key)

다른 데이터들과 구별되는 고유 값

중복되면 값이 DB에 들어갈 수 없으며 PK 값은 변경 불가능

 

 

* 테이블을 생성하고 권한을 스키마에 부여해야 함

Mysql에서,

 

Administration -> Users and Privileges -> Schema Privileges 탭 선택 -> Add Entry 클릭

Selected schema에서 원하는 스키마를 선택-> Select "ALL" 버튼 누르고 Apply 

 

* 데이터를 Commit하기 전에 Auto Commit 여부와

Edit 탭 -> Preference -> SQL Editor -> 맨 아래 Safe updates 체크 여부 확인하자

 

* rollback은 가장 마지막 Commit 상태로 돌아가게 함.

 

 

Spring으로 DB 연결하기

 

일일이 DB의 URL과 아이디, 비밀번호를, DB를 사용할 때마다 입력할 필요 없이

root-context.xml의 Beans태그 안에 Bean으로 등록해놓으면 편리하게 사용할 수 있다.

 

<bean id="dataSource" class="org.springframework.jdbc.datasource.DriverManagerDataSource">
    <property name="driverClassName" value="com.mysql.jdbc.Driver"></property>
    <property name="url" value="jdbc:mysql://localhost:3306/springbasic?useUnicode=true&amp;characterEncoding=utf8"></property>
    <property name="username" value="asdf"></property>
    <property name="password" value="1234"></property>
</bean>

다음과 같은 코드를 MySQL에 대한 정보를 등록하였다.

(username과 password는 생성한 개인 계정을 사용하면 된다)

 

- TDD

Test Driven Development(테스트 주도 개발) : JUnit이라는 테스트 프레임워크를 이용해서 테스트를 자동화한다.

테스트할 코드가 많아도 테스트 통과 여부를 쉽게 알 수 있음.

 

@RunWith(SpringJUnit4ClassRunner.class) // ac를 자동으로 만들어줌
@ContextConfiguration(locations = {"file:src/main/webapp/WEB-INF/spring/**/root-context.xml"}) // root-context.xml을 설정파일로 이용함.
public class DBConnectionTest2Test {
    @Autowired
    DataSource ds;

    @Test // 테스트할 메서드에 붙인다
    public void insertUserTest() throws Exception {
        
// 		ac를 @RunWith가 자동으로 만들어줌
//      ApplicationContext ac = new GenericXmlApplicationContext("file:src/main/webapp/WEB-INF/spring/**/root-context.xml");
//      DataSource ds = ac.getBean(DataSource.class); // @Autowired에 의해 ds가 생성됨

        
        User user = new User("asdf2","1234","abc","aaa@aaa.com",new Date(), "fb", new Date());
        deleteAll();
        int rowCnt = insertUser(user);

        assertTrue(rowCnt==1);
    }
    
}

테스트 클래스에는 @RunWith와 @ContextConfiguration 을 붙여야 함.

 

DataSource는 root-context.xml에 bean으로 등록했기 때문에 Autowired로 주입이 가능함.

 

메서드의 결과는 assert문의 조건식이 true이면 성공이고, false면 실패이다.

insertUser(user) 와 같은 데이터를 생성, 읽기, 수정, 삭제하는 메서드들은 int를 반환하는데, 

데이터베이스의 변화가 몇 줄을 변화시키느냐에 따라 반환값이 다르다.

변화가 있으면 보통 1을 반환(한 줄이 변함)하고 변화가 없으면 0을 반환한다.

 

 

DAO의 작성과 적용

 

- DAO(Data Access Object)

 

데이터(data)에 접근(access)하기 위한 객체(object)이다.

Database에 저장된 데이터를 읽기, 쓰기, 삭제, 변경을 수행(CRUD)한다.

DB테이블당 하나의 DAO를 작성한다(1 : 1 대응)

 

- 계층(layer)의 분리

 

각 컨트롤러에서 중복으로 사용하는 메서드들이 있다면, 따로 분리하여 메서드를 호출하는 식으로 중복을 제거하는 것이 좋다.

또한 관심사의 분리와 메서드의 변경에 유리하도록 하기 위해 계층을 나눠서 메서드를 관리한다.

 

Dao를 영속 계층(Persistence Layer, Data Access Layer)이라 하고

Service를 비즈니스 계층(Business Layer)이라 하며

Controller들을 표현 계층(Presentation Layer - Data를 보여주는 계층) 이라 한다.

 

계층관의 관계는 다음과 같다.

UI <ㅡ> Presentation Layer <ㅡ> Business Layer <ㅡ> Persistence Layer <ㅡ> Database 

 

 

 

- DAO 작성하기

 

인터페이스 추출을 통해 UserDao를 인터페이스로 추출하고,

UserDao를 구현하는 클래스인 UserDaoImpl 클래스를 만들어준다.

인터페이스를 통해 느슨한 연결을 하면 구현체의 변경이 자유로워지기 때문이다.

 

UserDao를 구현한 UserDaoImpl은 @Component 대신 @Repository 를 사용하여 빈을 생성한다.

@Repository에는 메타 애너테이션으로 @Component가 포함되어 있기 때문에

Component-scan 태그에 의해 scan이 되어 Bean이 생성된다.

Bean을 생성했으므로 @Autowired를 통해 DAO를 주입받을 수 있다.

 

DAO를 만들었다면 Test 메서드를 만들어서 잘 작동하는지 꼼꼼하게 테스트를 해야 한다.

 

 

Transaction, Commit, Rollback

 

- Transaction

 

더 이상 나눌 수 없는 작업의 단위이다.

 

예를 들어 계좌 이체의 경우, 출금과 입금이 하나의 Transaction으로 묶여야 됨.

출금과 입금이 모두 성공하지 않으면 모두 취소가 되어야 하기 때문이다.

 

 

- Transaction의 속성

 

ACID)

원자성(Atomicity) - 나눌 수 없는 하나의 작업으로 다뤄져야 한다.

일관성(Consistency) - Tx 수행 전과 후가 일관된 상태를 유지해야 한다 (Tx 수행의 결과에 오차가 없어야 한다)

고립성(Isolation) - 각 Tx는 독립적으로 수행되어야 한다 (Isolation level에 따라 각 Tx가 서로 영향을 줄 수도 있음)

영속성(Durability) - 성공한 Tx의 결과는 유지되어야 한다.

 

 

- 커밋(commit)과 롤백(rollbock)

 

커밋(commit) - 작업 내용을 DB에 영구적으로 저장한다

롤백(rollback) - 최근 변경사항을 취소(가장 마지막의 커밋으로 복귀하게 됨)

 

- 자동 커밋과 수동 커밋

 

자동 커밋 - 명령 실행 후, 자동으로 커밋이 수행(rollback불가)

수동 커밋 - 명령 실행 후, 명시적으로 commit 또는 rollback을 입력해야 DB가 변함.

 

- Tx의 isolation level

 

READ UNCOMMITED(dirty read) : 커밋되지 않은 데이터도 읽기 가능.

ex) Tx1 에서 데이터를 INSERT하고 아직 커밋을 하지 않은 상태에서

Tx2가 데이터를 SELECT 하면, 커밋되지 않은 데이터도 SELECT문에 의해 선택이 됨.

isolation level이 가장 낮음.

READ COMMITED : 커밋된 데이터만 읽기 가능

ex) Tx1 에서 데이터를 INSERT하고 아직 커밋을 하지 않은 상태에서

Tx2가 데이터를 SELECT 하면, 커밋되지 않은 데이터는 SELECT문에 의해 선택이 되지 않음.

 

REPEATABLE READ : Tx이 시작된 이후 변경은 무시됨 (default)

ex) Tx1이 시작된 상태에서 아직 종료되지 않았다면(commit을 누르지 않은 상태),

Tx2에서 데이터를 INSERT 하고 커밋을 해도 Tx1이 SELECT 문의 결과가 달라지지 않음.

 

SERIALIZABLE : 한번에 하나의 Tx만 독립적으로 수행

isolation level이 가장 높음. 직렬화 되어있음.

병렬처리(여러 Tx가 동시에 수행되는것)시 data가 품질이 떨어질 가능성이 있음.

(SERIALIZABLE 에서도 다른 Tx가 읽는것은 가능함. SELECT는 실행 가능)

ex) Tx1이 먼저 진행중이라면, Tx2의 INSERT 작업이 진행이 안 되고 기다림.

Tx1의 작업이 다 끝나면 Tx2의 INSERT 작업이 실행됨. 

 

 

 

---

출처 : 스프링의 정석 : 남궁성과 끝까지 간다