일반적으로 사용되는 여러 Python 웹 프레임워크에 대해 심층적으로 이해합니다.

다양한 언어 플랫폼 중에서 웹 프레임워크가 가장 많이 등장하는 곳은 아마도 Python일 것입니다. 수많은 마이크로 프레임워크와 프레임워크가 있는 세상이 바로 Python으로 프레임워크를 구성하는 것이 매우 간단하기 때문일 것입니다. , 만들기 바퀴는 계속해서 발명됩니다. 그래서

Python 커뮤니티에는 Python 프레임워크가 더 좋고 나쁘다는 주제가 항상 있습니다. 몇 가지 주요 Python 프레임워크를 소개하겠습니다.

Django

Django는 가장 유명한 Google App Engine이어야 하며 Erlang에도 이를 지원하는 프레임워크가 있습니다. 영향.

Django는 완전 자동화된 관리 백엔드로 가장 유명합니다. ORM을 사용하고 간단한 객체 정의만 하면 자동으로 데이터베이스 구조와 전체 기능을 생성할 수 있습니다. 배경.

Django가 제공하는 편리함은 Django에 내장된 ORM이 프레임워크의 다른 모듈과 긴밀하게 결합되어 있음을 의미합니다.

애플리케이션은 Django에 내장된 ORM을 사용해야 합니다. 그렇지 않으면 이론적으로 프레임워크에서 제공되는 다양한 ORM 기반 편의를 누릴 수 없으며 ORM 모듈을 전환할 수 있지만 이는 동일합니다. 집을 허물고 개조하려면 거친 집에 가서 처음부터

새 장식을 하는 것이 좋습니다.

Django의 장점은 개발 효율성이 매우 높다는 점이지만 성능 확장에는 제한이 있습니다. 따라서 Django를 사용하는 프로젝트는 성능 요구 사항을 충족하기 위해 트래픽이 일정 규모에 도달한 후에 재구성해야 합니다.

Django의 단점은 주로 Django가 모든 시스템을 자체적으로 만들겠다는 고집에서 비롯됩니다. Django의 가장 비판적인 측면은 다음과 같습니다.

· 시스템이 긴밀하게 결합되어 있습니다. Django에 특정 기능이 내장되어 있다고 생각한다면 그다지 좋지 않으며 아래에서 언급할 ORM 및 템플릿과 같이 선호하는 타사 라이브러리로 교체하기가 어렵습니다. Django에서는 SQLAlchemy나 Mako를 사용하는 것이 거의 불가능하며 일부 패치를 적용하더라도 매우 어색한 느낌을 줄 수 있습니다.

· Django와 함께 제공되는 ORM은 SQLAlchemy보다 훨씬 덜 강력합니다. Django를 제외하고 SQLAlchemy는 Python 세계에서 사실상의 ORM 표준이지만 Django는 여전히 이를 고집합니다. 세트. Django의

개발자들도 SQLAlchemy를 지원하기 위해 논의하고 시도했지만 결국 비용이 너무 비싸고 다른 Django 모듈과의 통합이 어렵다고 추정됩니다.

· 템플릿 기능은 상대적으로 약하고 Python 코드에 삽입할 수 없습니다. 더 복잡한 논리를 작성하려면 Python을 사용하여 태그 또는 필터를 구현해야 합니다. Django의 템플릿 시스템 디자인은 매우 흥미롭고 프레임워크에서 가장 영향력 있고 논쟁의 여지가 있는 부분이기도 합니다.

Django 템플릿의 디자인 철학은 코드와 스타일을 완전히 분리하는 것입니다. asp.net은 코드/템플릿 분리를 옹호하지만 기술적으로는 여전히 혼합될 수 있으며 Django는 기본적으로 템플릿에서 코딩을 제거합니다. 데이터 처리.

예를 들어 asp.net 템플릿에서는 다음과 같이 작성할 수 있습니다.

<%

int i;

for(i==0; i<10;i++){

....

}

%>

Django는 위와 유사한 삽입 코드를 지원하지 않습니다. 모두. 템플릿에 내장된 기능만 사용할 수 있습니다. 실제로 이 "새 언어"는 매우 간단하기 때문에 템플릿을 다른 플랫폼으로 이식할 수도 있습니다.

대부분의 경우 Django의 템플릿 기능으로 충분하지만 특별한(때때로 "특별한" 것이 그다지 특별하지 않은) 상황에서는 여전히 템플릿에 코드를 포함해야 하며 템플릿 시스템 규칙을 따라야 합니다. 템플릿 확장을 위해. 때로는 코드 한 줄로 템플릿에 직접

을 작성해서 해결할 수 있는 문제가 템플릿 확장으로 구현하고 나면 십여 줄이 넘는 코드가 되기도 합니다.

템플릿 프로그래밍이 허용되는지 여부는 Django 템플릿에서 가장 논란이 되는 측면입니다.

Django 외에 또 다른 큰 것은 Pylons입니다. TurboGears2.x는 Pylons를 기반으로 하고 repoze.bfg도 Pylons 프로젝트라는 대형 프로젝트에 편입되었으며, TurboGears와 repoze.bfg에 대해서는 추후 따로 다루지 않겠습니다.

Pylons와 Django의 디자인 컨셉은 완전히 다릅니다. Pylons 자체에는 약 2천 줄의 Python 코드만 있지만 Pylons에서 거의 사용하는 일부 타사 모듈도 함께 제공됩니다. Pylons는 선반과 옵션을 하나만 제공하므로 자신의 취향에 맞게 맞춤 설정할 수 있습니다

템플릿, ORM, 양식, 인증 등과 같은 구성 요소를 자유롭게 선택할 수 있어 시스템을 고도로 맞춤화할 수 있습니다. 우리는 종종 Python을 Glue 언어라고 말하므로 Pylons는 Glue 언어로 설계된 Glue 프레임워크라고 확실히 말할 수 있습니다.

Pylons를 선택하는 것은 아마도 자유를 선택하는 것과 같습니다.

· 학습의 악몽인 Pylons는 Made in Pylons가 아닌 많은 타사 라이브러리에 의존합니다. Pylons를 배우려면 이러한 라이브러리를 사용하는 방법도 배워야 합니다. 중요한 점은 때로는 무엇을 배우고 싶은지 알 수 없다는 것입니다. Pylons의 학습 곡선은 Django의 학습 곡선보다 훨씬 높으며, Pylons의 공식 문서는 비판의 대상이 되었습니다. 다행히도 나중에 The Definitive Guide to Pylons라는 책이 출판되었습니다. 이러한 이유로 Pylons는 한때 전문가에게만 적합한 Python 프레임워크로 알려졌습니다.

· 디버깅 악몽은 관련된 모듈이 많기 때문에 오류가 발생하면 문제를 찾기가 어렵습니다. 작성한 프로그램의 문제일 수도 있고, Pylons가 잘못되었거나, SQLAlchemy가 잘못되었거나, formencode에 버그가 있는 것일 수도 있습니다. 어쨌든 매우 지저분합니다

. 이 문제는 잘 알고 있어야만 해결할 수 있습니다.

· Pylons를 설치하려면 각각 고유한 버전 번호가 있는 거의 20개의 Python 모듈을 설치해야 합니다. 기본적으로 모든 모듈에는 비호환성 문제가 있을 수 있습니다. 매우 어렵습니다. 지금까지 Reddit의 Pylons는 여전히

골동품 버전 0.9.6에 머물러 있고 SQLAlchemy는 여전히 버전 0.5.3에 있는데, 이는 이와 관련이 있을 것입니다.

Pylons와 repoze.bfg의 통합은 Django의 위상에 도전할 수 있는 다음 프레임워크를 탄생시킬 수 있습니다.

Tornado( http://www.tornadoweb.org )는 Facebook의 오픈 소스 프레임워크와 거의 반대되는 철학을 가지고 있습니다. 장고. Tornado는 웹 서버(이 기사에서는 이에 대해 자세히 설명하지 않음)이며 web.py와 유사한 마이크로 프레임워크이기도 합니다.

Tornado는 더 적지만 더 나은 방향을 취하고 있습니다. 또한 권장되지는 않지만 작성자는 템플릿에 소량의 코딩을 허용할 수 있습니다(Py 코드 한 줄 직접 삽입). .

asp.net과 비교하면 Tornado는 약간 유사하며 그 외에는 AsyncHttpHandler만 구현하므로 모든 것을 직접 구현해야 합니다.

사실 템플릿, 국제화 지원, 심지어 내장 OAuth/OpenID 모듈까지 있어 제3자 로그인을 용이하게 합니다. 실제로 HTTP 서버를 직접 구현합니다.

하지만 ORM(mysql의 매우 간단한 캡슐화)도 없고 Django와 같은 자동화된 백엔드는 물론이고 세션 지원도 없습니다.

대규모 웹사이트라고 가정해 보겠습니다. 고성능 요구사항에 따라 프레임워크의 각 부분을 맞춤설정해야 하는 경우가 많고, Django로 개발된 웹사이트의 경우 재사용할 수 있는 모듈이 거의 없습니다. Django 프레임워크의 나머지 부분은 처음부터 tornado가 제공할 수 있는 것일 가능성이 높습니다.

다른 길은 같은 목적지로 이어진다.

Tornado는 HTTP 인터페이스에 대한 Comet/백엔드 비동기 호출을 효율적으로 구현하기 위해 HTTP 서버를 직접 내장합니다. 프런트엔드는 apache/lighthttpd/nginx 등을 추가하지 않고도 브라우저에서 접근할 수 있지만 HTTP 1.1 프로토콜을 완전히 구현하지 않으므로 공식 문서에서는 사용자에게 프론트엔드에서 nginx를 사용할 것을 권장합니다. -프로덕션 환경의 엔드 및 백엔드 여러 Tornado 인스턴스에 대한 역방향 프록시.

Tornado 자체는 단일 스레드 비동기 네트워크 프로그램입니다. 기본적으로 시작되면 멀티 코어 CPU를 최대한 활용하여 CPU 수에 따라 여러 인스턴스를 실행합니다.

웹사이트는 기본적으로 데이터베이스 작업이 있고 Tornado는 단일 스레드이므로 데이터베이스 쿼리가 너무 느리게 반환되면 전체 서버 응답이 막히게 됩니다. 데이터베이스 쿼리는 본질적으로 원격 네트워크 호출입니다. 이상적으로 이러한 작업은 비동기식으로 캡슐화되지만 Tornado는 이에 대한 지원을 제공하지 않습니다.

시스템이 높은 트래픽을 충족하려면 데이터베이스 쿼리 속도 문제를 해결해야 합니다!

데이터베이스에 쿼리 성능 문제가 있으면 아무리 전체 시스템을 최적화해도 데이터베이스가 병목 현상을 일으키고 전체 시스템 속도를 저하시키게 됩니다!

비동기식은 본질적으로 시스템 성능을 향상시키지는 **않습니다**. 단순히 네트워크 응답을 불필요하게 기다리거나 스레드 전환의 CPU 소비를 방지할 뿐입니다.

데이터베이스 쿼리 응답이 너무 느린 경우 해결해야 할 것은 데이터베이스를 호출하는 프런트엔드 웹 애플리케이션이 아니라 데이터베이스의 성능 문제입니다.

실시간 반환된 데이터 쿼리의 경우 이상적으로는 모든 데이터가 메모리에 있고 데이터베이스 하드 디스크 IO가 0이어야 합니다. 이러한 쿼리는 데이터베이스 쿼리가 충분히 빠른 경우에만 가능합니다. , 그러면 프런트엔드 웹 애플리케이션은 다음을 수행할 수 없습니다. 데이터 쿼리를 비동기식

으로 캡슐화해야 합니다.

코루틴을 사용하더라도 비동기 프로그램은 항상 동기 프로그램의 복잡성을 증가시킵니다. 측정해야 할 것은 추가적인 복잡성을 처리할 가치가 있는지 여부입니다.

백엔드에 너무 느리고 우회할 수 없는 쿼리가 있는 경우 Tornaod는 이러한 쿼리를 백엔드에서 독립적으로 HTTP 인터페이스로 캡슐화한 다음 Tornado에 내장된 비동기 HTTP 클라이언트를 사용하여 호출하는 것을 제안합니다. .

위 내용은 일반적으로 사용되는 여러 Python 웹 프레임워크에 대해 심층적으로 이해합니다.의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!