1. Framework vs Library
| 성격 | 재사용 가능한 하나 이상의 서브루틴(함수)들이 저장된 파일들의 모음 | 서로 관련이 있는 많은 수의 문제를 풀기 위한 추상적 설계를 구체화한 클래스 집합 |
| 사용자 코드의 작성 | 독립적으로 작성 | 프레임워크 클래스를 상속하거나 참조하여 코드를 작성 |
| 호출 흐름 및 제어 권한 | 사용자 코드가 라이브러리 코드를 호출하고, 또한 제어하는 구조 | 프레임워크 코드가 유저 코드를 호출하고, 제어하는 구조(IoC, Inversion of Control) |
| 특징 | 프로그램(사용자 코드)이 활용하는 대상 | 프로그램(사용자 코드)이 준수하는 대상 |
2. Framework vs Component레브네인의 이야기]
| 성격 | 컨테이너라고 하는 기반 구조에서 작동하는 컴포넌트 모듈에 초점 | 어플리케이션 기반 구조에 초점 |
3. Framework vs Design Pattern
| 성격 | ‘추상적인 무엇‘으로 일반화 | ‘실제적인 어떤 것‘으로 특정 애플리케이션 도메인 영역에 특화 |
| 기능 | 어플리케이션 설계 시 구조적인 가이드 라인을 제공 | 프레임워크는 하나 이상의 디자인 패턴을 지원 |
| 구현부의 제공 여부 | 구체적으로 구현된 기반 코드가 없다(샘플 코드 정도를 포함). | 기반 코드를 제공해서, 자연스럽게 패턴을 유도한다. |
| 예시 | MVC(Model-View-Controller) Pattern | Spring-MVC 프레임워크, Struts 프레임워크 |
4. Framework와 Architecture
| 성격 | 하나 이상의 프레임워크로 구성 | 어플리케이션의 구조를 결정 |
Framework = Design Pattern + Library
Architecture = Structure + Framework
728x90