SOLID (솔리드) 원칙이란?

SOLID원칙은 읽기 쉽고, 적응 가능하며,
확장 가능한 코드를 생성하는 객체 지향 프로그램 (OOP) 의 5가지 설계 원칙.
다음 5가지 원칙의 앞글자를 따서 SOLID 라고 부른다.

1. Single-responsibility principle (단일책임 원칙) “같은 이유로 변화된 것들을 모아서 다른 이유로 변화된 것들을 분리해야 한다.”

2. Open-closed principle (개방폐쇄 원칙) “소프트웨어 엔티티 (클래스, 모듈, 기능 등) 는 확장에는 개방하되 수정에는 폐쇄해야 한다.”

3. Liskov substitution principle (리스코프 치환 원칙) “수퍼 클래스의 객체는 그 응용 프로그램을 깨지 않고 하위 클래스의 객체와 교체할 수 있어야 한다.”

4. Interface segregation principle (인터페이스 분리 원칙) “Client는 사용하지 않는 인터페이스에 의존하도록 강요되어서는 안 된다.”

5. Dependency inversion principle (의존성 역전 원칙) “높은 수준의 모듈은 낮은 수준의 모듈에 의존해서는 안된다.

둘 다 추상적 개념에 의존해야 한다” “추상화는 세부사항에 의존해서는 안 된다. 세부 사항은 추상적 개념에 의존해야 한다.”
이 원칙들 중 어떤 것도 진정으로 배타적인 것은 아니다. 서로 포괄적이라고 주장할 수도 있다. 이들 중 일부는 하나의 목표를 추구하는 데 각각의 역할을 하는 여러 전략을 나타낸다. 예를 들어, 인터페이스 분리 원칙은 여러 가지 면에서 단일 책임 원칙에 대한 반영이다.
만약 후자가 올바르게 구현된다면, 전자는 전형적으로 따를 것이다.
마찬가지로, 개발자들이 개방-폐쇄 원칙 및 리스코프 치환 원칙을 면밀히 따른다면 종속 역전 원리는 쉽게 지켜질 수 있다.
“어렵지만 그래도 편한 Java진영 DB연동 framework”

장점

1. DB와의 연계를 편하게 해주는 Java 진영의 대표적인 framework
2. 단순JDBC보다 좀더 간편하게 DB접근이 가능하다. 코드수를 줄일 수 있고, 이에 따라 생산성이 늘어난다.
3. 복잡한 쿼리도 동적으로 구현가능하다. if문을 사용해서도 가능하고, iterate 등도 사용가능하다. 훨씬 쉽게 쿼리 작성이 가능하다.

단점

1. 복잡한 설정 : mybatis 뿐만이 아니라 이것을 사용하기 위한 여러 dependecy들이 존재하며, 설정을 위해 xml 설정파일도 수정해주어야 한다.
   웹문서/블로그들에 잘 나와있긴 하지만, 잘못되어있거나 버전이 다를경우엔 정상적으로 동작하지않기도 한다.
   또한, config 파일의 위치가 폴더 깊숙한 곳에 위치하게 된다.
2. 수많은 xml과 : context-mapper.xml, context-datasource.xml, 쿼리를 위한 xml,
   그리고 이를 위한 각각의 java class 생성이 필요하다. 간단한 기능하나 만드는데 족히 10개 내외의 파일 수정/생성이 필요해보인다.
3. 디버깅하기 어려울 수 있다 : JDBC는 break point로 디버깅을 상대적으로 쉽게 할 수 있는 반면, mybatis는 break point를 따로 잡을 수 없기에 디버깅이 어려워질수 있다.

총평

ibatis때부터 써봤었는데, 설정하는것도 복잡하고 mybatis를 사용하기 위한 파일들을 많이 생성해야하는것도 여간 귀찮은게 아니다.
하지만 spring쓰는 프로젝트에서는 항상 이 프레임워크를 써왔기때문에 어쩔수 없이 쓰긴한다.
그래도 JDBC를 생으로 쓰는것보다는 훨씬 낫다.
기회만 된다면 다음번에는 JPA도 사용해보고 프로젝트마다 어떤 것을 쓰면 좋을지 경험을 축적하는게 좋을거 같다.