Django와 다른 Python 웹 프레임워크?

https://stackoverflow.com/questions/702179

22-08-2019
|

문제

나는 존재하는 모든 Python 웹 프레임워크를 거의 모두 시도해 보았고, 만능 프레임워크가 없다는 것을 깨닫는 데 오랜 시간이 걸렸습니다. 각 프레임워크에는 고유한 장점과 단점이 있었습니다.나는 시작했다 Snakelets 큰 소란 없이 낮은 수준에서 거의 모든 것을 제어할 수 있다는 사실이 진심으로 기뻤습니다. 터보기어 그 이후로 나는 그것을 (1.x) 사용해 왔습니다.Catwalk 및 웹 콘솔과 같은 도구는 나에게 매우 중요합니다.

하지만 WSGI를 지원하는 TurboGears 2가 출시되고 Django와 WSGI 진영 간의 종교적 논쟁을 읽은 후 저는 정말 고민 중입니다. "올바른 방법으로 하는 것", 예를 들어 Django나 나를 위해 모든 작업을 수행하는 일부 고급 프레임워크를 사용하는 대신 WSGI를 배우고 Django 및 기타 풀 스택 프레임워크에 이미 존재하는 기능을 작성하는 데 귀중한 시간을 소비합니다.내가 볼 수 있는 후자의 단점은 매우 분명합니다.

나는 그 과정에서 아무것도 배우지 못한다.
더 낮은 수준의 작업을 수행해야 한다면 고통스러울 것입니다.
인증을 사용하는 기본 사이트에만 필요한 오버헤드는 엄청납니다.(IMO)

그래서 내 질문은 어느 것이 더 나은 선택인지, 아니면 단지 의견의 문제인지, 그리고 최소한의 소란으로 내가 원하는 것을 달성한다면 Django를 사용해야 하는가입니다(저는 인증과 CRUD 인터페이스를 원합니다). 내 데이터베이스)?Werkzeug, Glashammer 및 친구들을 사용해 보았지만 AuthKit과 Repoze는 물론 기본 인증을 설정하는 데 필요한 단계 수도 겁이 났습니다.Pylons를 봤는데 문서가 부족한 것 같고 인증이나 CRUD 인터페이스와 같은 간단한 기능을 참조할 때 다양한 위키 페이지와 문서가 서로 모순되는 것처럼 보였고 버전에 대한 해킹도 다릅니다.

S에게 감사드립니다.내가 충분히 명확하지 않았다는 점을 지적해 준 로트.내 질문은 다음과 같습니다다음 중 장기적으로는 가치가 있지만 단기적으로는 고통스럽지 않은 것은 무엇입니까? (예: 일종의 중간 지점에 있는 분 계시나요?) - WSGI를 배우시겠습니까, 아니면 "배터리 포함" 프레임워크를 고수하시겠습니까?후자라면 Django를 다시 시도해 볼 것인지, TurboGears 1.x를 계속 사용할 것인지, 아니면 다른 프레임워크를 시도해 볼 것인지 제안해 주시면 감사하겠습니다.

또한 CherryPy를 사용해 보았지만 바로 실행해서 사용할 수 있을 만큼 충분히 좋은 CRUD 애플리케이션을 찾지 못한 것 같습니다.

해결책

TG2를 다시 살펴 보는 것이 좋습니다. 나는 사람들이 마지막 버전 이후로 만들어진 걸음 중 일부를 알아 차리지 못했다고 생각합니다. 이용 가능한 유틸리티의 증가 된 WSGI 스택 외에도 고려해야 할 TG2 특정 품목이 꽤 많이 있습니다. 다음은 몇 가지 하이라이트입니다.

터보 가어 관리 시스템 - 데이터베이스에 대한이 CRUD 인터페이스는 선언적 구성 클래스를 사용하여 완전히 사용자 정의 할 수 있습니다. 또한 Dojo와 통합되어 무한히 스크롤 가능한 테이블을 제공합니다. 서버 측 유효성 검증도 자동화됩니다. 관리자 인터페이스는 RESTFUL URL 및 HTTP 동사를 사용하므로 업계 표준을 사용하여 프로그래밍 방식으로 쉽게 연결할 수 있습니다.

CrudRestController/RestController - 터보 가어는 컨트롤러에서 서비스를 처리하는 구조화 된 방법을 제공합니다. RestController를 확장하여 표준화 된 HTTP 동사를 사용할 수있는 기능을 제공합니다. 결합하다 Sprox CrudRestController를 사용하면 완전 정복 가능한자가 생성 형태로 응용 프로그램의 어느 곳에서나 Crud를 넣을 수 있습니다. TurboGears는 이제 URL의 파일 확장으로 MIME 타입을 지원하므로 HTML 렌더링에 사용하는 것과 동일한 인터페이스를 사용하여 컨트롤러 렌더링 .json 및 .xml (컨트롤러에서 사전을 반환) 할 수 있습니다.

링크를 클릭하면 과거의 문서보다 더 광범위한 Sphinx로 구축 된 새로운 문서 세트가 있음을 알 수 있습니다.

최고로 웹 서버, ORM, 그리고 템플릿 시스템(S) (자신의 선택) 후드 아래에서, 왜 TG가 빠르게 가고 싶은 사람들에게 TG가 의미가 있고 사이트가 성장함에 따라 확장 성을 가진 이유를 쉽게 알 수 있습니다.

Turbogears는 종종 움직이는 목표를 달성하려고하는 것으로 보이지만, 우리는 릴리스에 대해 일관성을 유지합니다. 즉, 필요한 최신 기능을 얻기 위해 트렁크에서 작업하는 것에 대해 걱정할 필요가 없습니다. 미래에 오는 것 : 더 많은 터보 가어 확장 기능이있어 애플리케이션이 파스터 명령의 용이성으로 기능을 향상시킬 수 있습니다.

다른 팁

Django 캠프와 WSGI 캠프 사이의 종교적 논쟁

WSGI가 무엇인지, Django가 무엇인지에 대해 약간 혼란스러워 보이는 것 같습니다.Django와 WSGI가 경쟁하고 있다고 말하는 것은 C와 SQL이 경쟁하고 있다고 말하는 것과 비슷합니다.당신은 사과와 오렌지를 비교하고 있습니다.

Django는 프레임워크이고, WSGI는 서버가 프레임워크와 상호 작용하는 방식에 대한 프로토콜(Django에서 지원)입니다.가장 중요한 것은 WSGI를 직접 사용하는 방법을 배우는 것은 어셈블리를 배우는 것과 비슷하다는 것입니다.이는 훌륭한 학습 경험이지만 실제로 프로덕션 코드에 대해 수행해야 하는 작업은 아니며 의도한 작업도 아닙니다.

어쨌든 내 조언은 스스로 알아내라는 것이다.대부분의 프레임워크에는 "한 시간 내에 위키/블로그/설문조사 만들기" 유형의 연습이 있습니다.각각에 대해 약간의 시간을 보내고 어느 것이 가장 마음에 드는지 알아내십시오.결국, 시도해 볼 의향이 없다면 어떻게 다른 프레임워크 중에서 결정할 수 있습니까?

나는 당신이 Django 또는 유사한 풀 스택 프레임 워크를 사용하여 "아무것도 배우지 않는다"는 것에 대해 너무 비관적이라고 말하고, 문서와 큰 커뮤니티의 가치를 과소 평가합니다. Django에도 여전히 상당한 학습 곡선이 있습니다. 그리고 원하는 모든 것을하지 않으면 프레임 워크 코드가 뚫을 수없는 것과는 다릅니다.

몇 가지 개인적인 경험 : 나는 몇 년 동안 켜고 끄는 데 보냈다. 프레임 워크 코드가 끊임없이 미완성되고 저 아래에 다시 작성 되었기 때문에 아무것도 끝내지 못했습니다. 문서는 종종 존재하지 않거나 잘못되었으며 IRC를 통한 유일한 지원은 종종 큰 조언을 얻었지만 저도 물어 보면 부과하는 것처럼 느꼈습니다. 많은 질문).

이에 비해 지난 몇 년 동안 나는 Django와 함께 몇 개의 사이트를 노크했습니다. 이전 경험과 달리 실제로 배치 및 실행 중입니다. Django 개발 프로세스는 느리고주의를 기울일 수 있지만 비트 롯트 및 감가 상각 및 실제로 도움이되는 문서가 훨씬 적습니다.

Django에 대한 HTTP 인증 지원 마침내 들어갔다 몇 주 전, 그것이 당신이 #3에서 언급하고 있다면.

귀하의 질문은 "WSGI를 배우고 모든 것을 직접 수행 할 가치가있는 것 같습니다"또는 "모든 일을하는 전체 스택 프레임 워크"를 사용하는 것 같습니다.

나는 그것이 거짓 이분법이라고 말하고 분명한 세 번째 방법이 있습니다. Turbogears 2는 "모든 것을 위해 모든 것을 위해"스타일 프레임 워크에서 WSGI 미들웨어에 대한 이해에 이르기까지 매끄러운 길을 제공하고 응용 프로그램의 요구에 맞게 프레임 워크의 거의 모든 측면을 사용자 정의 할 수있는 능력을 제공합니다.

우리는 모든 수준에서 모든 장소에서 성공하지 못할 수도 있지만, 특히 이미 Turbogears 1 경험이 있다면 TG2 학습 곡선이 처음에는 매우 쉬우 며 정확히 더 깊이 갈 수있는 능력이있을 것이라고 생각합니다. 당신은 그것을 필요로합니다.

특정 문제를 해결하려면 :

우리는 TG1에서 사용 된 것과 일치하는 인증 시스템을 상자에서 제공합니다.
우리는 tgext.admin이라는 인터페이스와 같은 상자에서 "django admin"을 제공합니다. Tgext.admin은 Dojo와 잘 작동하여 인터페이스와 같은 멋진 스프레드 시트를 기본값으로 만듭니다.

나는 또한 거기에있는 다른 옵션들 중 몇 가지를 해결하고 Benifits에 대해 조금 이야기하고 싶습니다.

체리. Cherrypy는 훌륭한 웹 서버이자 멋진 최소한의 웹 프레임 워크라고 생각합니다. 내부적으로 WSGI를 기반으로하지는 않지만 "풀 스택"경험을 제공하지는 않지만 WSGI 지원이 우수합니다. 그러나 Django 또는 Turbogears가 제공하는 불이행에 특히 적합하지 않은 사용자 정의 설정의 경우 훌륭한 솔루션입니다.
장고. Django는 웹 사이트를 개발하기위한 매우 훌륭하고 엄격하게 통합 된 시스템이라고 생각합니다. 응용 프로그램과 작업 스타일이 표준 설정에 잘 맞는 경우 환상적 일 수 있습니다. 그러나 DB 사용을 조정하거나 템플릿 언어를 교체하거나 다른 사용자 인증 모델을 사용하거나 다른 작업을 수행하면 프레임 워크와 싸우는 것을 알 수 있습니다.
철론 Cherrypy와 같은 Pylons는 훌륭한 미니멀리즘 웹 프레임 워크입니다. Cherrypy와 달리 WSGI는 전체 시스템을 통해 활성화되어 있으며 SQLALCHEMY 및 MAKO와 같은 제정신 기본값을 제공하여 확장에 도움이됩니다. 새로운 공식 문서는 당신이 보았던 구형 위키 문서보다 품질이 훨씬 우수합니다.

Cherrypy를 보셨습니까? 미니멀하지만 효율적이고 단순합니다. 그것들이 그들에게 들어 가지 않을 정도로 충분히 낮지 만 복잡성을 숨길만큼 높습니다. 내가 잘 기억한다면, 터보 가어가 그 위에 세워졌습니다.

Cherrypy와 함께, 당신은 많은 것을 선택할 수 있습니다. (템플릿 프레임 워크, ORM 원하는 경우, 백엔드 등)

WSGI를 배우십시오

WSGI는 터무니없이 단순합니다. 기본적으로 보이는 함수입니다.

def application(environ, start_response) pass

HTTP 요청이 수신되면 기능이 호출됩니다. environ 요청 URI 등과 같은 다양한 데이터가 포함되어 있습니다. start_response 헤더를 설정하는 데 사용되는 호출 기능입니다.

반환 된 값은 웹 사이트의 본문입니다.

DEF 응용 프로그램 (Environ, Start_Response) : start_Response ( "200 OK", []) return "..."

그게 전부입니다. 정말 .. 그것은 프레임 워크가 아니라 웹 프레임 워크가 사용할 수있는 프로토콜입니다 ..

사이트를 만들기 위해서는 WSGI를 사용합니다 ~ 아니다 "올바른 방법" - 기존 프레임 워크를 사용하는 것은 .. 그러나 Python Web -Framework를 작성하는 경우 WSGI를 사용하는 것은 절대적으로 올바른 방법입니다.

사용하는 프레임 워크 (Cherrypy, Django, Turbogears 등)는 기본적으로 개인적인 취향입니다. 각각에서 놀고, 가장 좋아하는 것을보고, 사용하십시오. "간단한 파이썬 프레임 워크에 대한 권장 사항"

web2py를 확인 했습니까? 최근에 많은 Python 웹 프레임 워크를 평가 한 후 최근에 나는 이것을 채택하기로 결정했습니다. 아직 그렇지 않은 경우 Google App Engine도 확인하십시오.

나는 정답이 당신이 실제로 원하는 것과 필요한 것에 달려 있다고 말하고 있습니다. 장기적으로 가치가있는 것은 장기적으로 필요한 것에 달려 있기 때문입니다. 목표가 최대한 빨리 응용 프로그램을 배치하는 것이 목표라면 '간단한'경로 (즉). Django는 반드시가는 길입니다. 당신이 원하는 것을 과소 평가할 수없는 잘 테스트되고 잘 문서화 된 시스템의 가치.

반면에 다른 도메인에 적용될 수 있고 커스터마이징을위한 가장 넓은 범위를 갖고 싶어하는 다양한 새로운 것들을 배울 시간이 있다면 터보 가어와 같은 것이 우수합니다. 터보 가어는 최대한의 유연성을 제공하지만 귀하는 귀하에게 최대한의 유연성을 제공합니다 ~ 할 것이다 REPOZE, SQLALCHEMY 및 GENSHI와 같은 것들에 대해 외부 문서를 읽는 데 많은 시간을 보내야합니다. TG2 문서는 외부 문서가 예전보다 낫다고 생각하기 때문에 경우에 따라 TG1 문서보다 의도적으로 덜 상세합니다. 이런 종류의 물건이 장애물인지 투자인지 여부는 자신의 요구 사항에 따라 다릅니다.

Django는 확실히 배울 가치가 있으며, 당신의 목적에 맞는 것처럼 들립니다. 함께 제공되는 관리자 인터페이스는 일어나기 쉽고 실행하기 쉽고 인증을 사용합니다.

"무엇보다 낮은 레벨"에 관해서는 SQL을 의미하는 경우 추가 키워드와 함께 SQL을 쿼리에 전적으로 밀어 넣을 수 있습니다. 문체 적으로, 당신은 항상 가능한 한 그것을 피하려고 노력합니다.

"아무것도 배우지 않는 것"에 관해서는 ... 진정한 질문은 당신의 선호가 주로 낮은 수준 또는 더 높은 수준의 것을 배우는 것인지 여부입니다. 여기서 누구나 당신에게 대답 할 수있는 질문은 거의 없습니다.

Pylons는 저에게 훌륭한 도구 인 것 같습니다.

실제 웹 프레임 워크 (Cherrypy는 단지 웹 서버),
소규모 코드 기반 - 다른 프로젝트 재사용,
페이스트를 기반으로 WSGI를 염두에두고 완전히 작성했습니다.
앱을 즉시 코딩하고 필요한 경우 낮은 레벨 비트를 터치 할 수 있습니다.

나는 Cherrypy와 Turbogears를 사용하고 다른 많은 프레임 워크를 보았지만 Pylons만큼 가볍고 생산적이지 않았습니다. 을 체크하다 Google에서 프레젠테이션.

나는 터보 가어스 팬입니다. 이것이 바로 그 이유입니다. 제어와 일을하는 것과 쉽게 일하는 것 사이의 아주 좋은 트레이드 오프입니다.

물론 자신의 마음을 구성해야합니다. 어쩌면 당신은 덜 배우고 싶어 할 것입니다. 내가 지식/제어를 좋아하는 영역 (예 : 데이터베이스)이 덜 신경 쓰지 않을 수도 있습니다. 그리고 오해하지 마십시오. 나는 어떤 프레임 워크를 반드시 어렵거나 잘못된 것으로 특성화하지 않습니다. 그것은 단지 나의 주관적인 판단 일뿐입니다.

또한 가능한 경우 Turbogears 2를 추천합니다. 그것이 나올 때, 나는 그것이 기본값 (Genshi, Pylons, Sqlalchemy)에 대해 선택한 측면에서 1.0보다 훨씬 나아질 것이라고 생각합니다.

나는 Turbogears 2를 제안합니다. 그들은 최고의 Python World를 통합하는 환상적인 일을했습니다.

WSGI : TG2 또는 다른 프레임 워크에서 적당히 복잡한 프로젝트/ 비즈니스 솔루션을 개발하고 있다고 가정하면 Grok. 이러한 프레임 워크가 WSGI를 지원하더라도 이러한 프레임 워크를 사용하는 사람이 WSGI를 배워야한다는 것을 의미합니까? 대부분의 경우 대답은 아니요입니다. 의심 할 여지 없이이 지식이 있다는 것을 의미합니다.

WSGI 지식은 아마도 다음과 같은 경우에 더 유용 할 것입니다.

예를 들어 표준 스택의 일부로 제공되지 않는 일부 미들웨어 또는 다른 구성 요소를 사용하려고합니다. tg 또는 authkit ZODB가없는 Grok.
당신은 약간의 통합을하고 있습니다.

체리 좋지만 트랜잭션이 끝날 때 데이터베이스 커밋/롤백을 처리하고 JSON 노출, 그러한 경우 유효성 검사, TG, Frameworks와 같은 프레임 워크가 모든 것을 수행하는 것을 생각해보십시오.

Web2py는 여기서 비밀 소스입니다. 확인하는 것을 놓치지 마십시오.

라이센스 : CC-BY-SA ~와 함께 속성

제휴하지 않습니다 StackOverflow