Framework

멀캠교육요약 1일차-Spring,Hibernate,ibatis

MorningPhys 2015. 7. 17. 22:55

** 느낌

그동안 '이렇게 개발하면 좋지 않아'라고 감으로 얘기했던 것을 체계적으로 설득하기 좋아졌다.

일 안하니까 좋다♡

 

** why framwork?

SUN에서 제시한 pure J2EE spec.으로 개발하기에는 번거로운 것이 너무 많다.

그래서 각 layer마다 framework 혹은 library로 조금이라도 쉽게 개발해 보자.

Layered architecture에서 개발할 때 표준 spec과 framework 위치 비교 그림 (아래)

 

 

** architecutre of F/W

대부분 어플리케이션 개발자는 Hook point와 hot spot만 보는 경우 많다.

F/W 사용하게 되면 (보통 xml로 구성되는) metadata를 많이 만들게 된다.

spring 2.5 이상 되면서 annotation을 이용해서 xml 이 너무 많아 지는 것을 줄 일 수 있지만,

소스코드에서 메타데이터를 분리한다는 사상에는 위배되서 딜레마에 빠지긴 했다.

 

** 유지보수성을 높일려면??

- 결합도를 낮춘다 -> IOC를 이용해서

- 응집도를 높인다 -> AOP를 이용해서

- OAOO (once and only once) 소스는 한번만 -> 요는 copy&paste 하지마라. 유지보수 떨어진다.

- OCP - (open-closed 설계) -> 재사용부분은 다른 사람이 내부 몰라도 쓸 수 없도록 가릴것 가리고 인터페이스 잘 오픈해서 쓰기 좋게 해라

 

** EJB vs. POJO

- EJB : Component 단위로 개발하자, Distribute환경에서 RMI관련 된 코드 개발자가 짤 필요 없이 spec에서 지원

- POJO : 순수 자바 외에 다른 spec은 사용하지 않음. 어떤 f/w을 사용하더라도 모두 수용

 

** Component vs. OOP

- OOP : Class 단위의 재활용성을 높이기 위해서는 좋지만 App.가 커지면서 단위 Class의 재활용은 의미가 적어짐

- Component : 이에따라 일정 덩어리의 Class를 묶어서 Component라고 묶어서 재활용 단위로 제공

 

** EJB에 비해 Srping F/W 좋은 점

1. EJB는 고비용이다.

2. Container Service 제공해 준다. -> 검증된 F/W을 제공해 주겠다.

3. Container Service 확장 좋다.

4. POJO

5. Distribute 환경은 X -> but 필요하면 확장 가능

6. 다른 F/W, 기술 쉽게 통합할 수 있다.

반응형