서버개발 = 파이썬, c++ , 자바
클리아이언트 개발 = 프레임워크 - 앵귤러, 리액트, 뷰
* spa = 하나의 페이지만 존재하는 웹 어플리케이션 , 전체 페이지 랜더링 하지 않고 부분 갱신 (비동기)
1. 장고는 MTV 아키텍쳐 이다.
M = 모델 (db) , T = 템플릿(ui 담당) , V = 뷰 (유저, 어플리케이션 요청과 응답 처리)
장고의 각 모듈과 매핑된다.
* 각 요소는 다른요소에게 영향 미치지 않아야
2. 장고는 풀스텍 프레임워크이다.
자체 ORM 을 가진 프레임워크
*ORM 객체와 관계형 데이터베이스의 데이터를 연결하는 기술 , class->테이블로
도메인과 모듈간 계층이 높은 응집도와 낮은 결합도를 가질 수 있도록 시스템 아키텍쳐 분리
높은 응집도 = 모듈내부의 기본적 응집정도 (연결정도)
낮은 결합도 = 다른 모듈과의 의존성 정도
*도메인 = 소프트웨어로 해결하고자 하는 문제 영역
*장고 앱 = 장고는 앱 단위로 도메인 분리 아키텍쳐 제공
*마이크로 프레임워크 <-> 풀스텍 프레임워크
3. 플라스크
파이썬 마이크로 프레임워크 가볍고 간결 , 자체 ORM 이 없어서 sqlalchemy 라는 프레임워크와 함께 사용,
가장 대중적인 마이크로 프레임워크
4. why 장고 ?
-대중성
-풀스택 프레임워크
-거대한 커뮤니티 조성
5.장고의 설계 철학
- 낮은 결합도
프레임워크의 각 계층 모듈은 서로 모르게 설계되어있음( 언제든 다른 모듈로 교체 가능하다. )
-암시적인 것보다 명시적인 것이 낫다.
암시적으로 동작하는 코드는 다른 개발자가 직관적으로 파악할 수 없다.
- 장고의 시그널
어떤 동작이 수행되었을때 이를 시놓로 받아서 다른동작을 수행하게 해 주는 기능
(암시적인 동작임으로 과도한 사용 x)
(models/sinal.py or views/signals.py 패키지 안에서막 작성)
(이력을 쌓아야 하는 경우에만 사용)
-모델 모듈이 도메인 로직을 캡슐화 하도록 작성
모델과 관련된 로직들을 모델 내부에서 관리 (class 로 묶자)
-효율적인 sql 수행
프레임워크 관점에서 sql 은 무거운 동작, 최대한 작게 수행
6. 장고 어드민
내부 직원이 사용하는 툴 즉 관리자 페이지 -> 적은 코드량으로 crud 처리 가능, but 프런트엔드로 확장 불가
*crud = creat (생성), read(읽기), update(갱신) , delete(삭제)
=> 복잡한 ui 는 불가하다.
7. 장고 라이브러리
-poetry : 파이썬 프로젝트 의존성 관리 도구 (pip 같은거 )
-mypy : 선택적 정적 타입 검사기 ( 타입이 명확하지 않으면 에러표시 , 개선안하면 코드 반영 안되게 할수도 있음)
(동적 언어제 정적인 제약 검사 추가하는것)
*타입 힌트 문법 파이썬 3.5 부터 지원, 함수 변수에 타입명시 가능하게됨
-blak : ( 소스코드 통일성을 위해 강제포매팅 해버림)
-django REST framework(DRF): 장고 백엔드 위한 필수 모듈 rest api 서버 구축 가능하게 해줌
-django-filter : 템플릿 개발시 데이터검색기능 쉽게 개발 가능하게함, drf와 연계해서 검색 api 만들때 검색 조건 갭라할수 있게 해줌
-django-extensions : 개발 편하게 해줌 ex) runserver_plus 사용하면 서버 start 명령어와 서버 로그가 깔끔하게 찍힘
-drf-spectacular : api 문서 자동화 도구 지원. drf 로 개발한 api 를 자동으로 문서화 해줌