** 느낌
그동안 '이렇게 개발하면 좋지 않아'라고 감으로 얘기했던 것을 체계적으로 설득하기 좋아졌다.
일 안하니까 좋다♡
** 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, 기술 쉽게 통합할 수 있다.
'Framework' 카테고리의 다른 글
멀캠교육요약 4일차-Spring,Hibernate,ibatis (0) | 2015.07.19 |
---|---|
멀캠교육요약 3일차(SpringMVC)-Spring,Hibernate,ibatis (0) | 2015.07.19 |
멀캠교육요약 3일차-Spring,Hibernate,ibatis (0) | 2015.07.19 |
멀캠교육요약 2일차(AOP)-Spring,Hibernate,ibatis (0) | 2015.07.19 |
멀캠교육요약 2일차-Spring,Hibernate,ibatis (0) | 2015.07.17 |