Bối cảnh yêu cầu toàn cầu - chống mẫu?

Hôm nay tôi đã nói chuyện với một đồng nghiệp của tôi về các khung web Python và ấn tượng của chúng tôi về chúng. Tôi nói với anh ấy rằng tôi nghĩ Flask có yêu cầu toàn cầu có mùi rất tệ và là một kiểu chống đối.

Các tài liệu nói về bối cảnh yêu cầu:

Ngược lại, trong khi xử lý yêu cầu, một vài quy tắc khác tồn tại:

• trong khi một yêu cầu được kích hoạt, các đối tượng cục bộ bối cảnh (jar.request và các đối tượng khác) trỏ đến yêu cầu hiện tại.
• bất kỳ mã nào cũng có thể có được các đối tượng này bất cứ lúc nào.

Tôi nghĩ rằng tôi hiểu ý tưởng đằng sau quyết định thiết kế này - để làm cho ứng dụng đơn giản hơn. Đó chỉ là một sự thỏa hiệp, như trong trường hợp của Chủ đề địa phương :

Có, nó thường không phải là một ý tưởng sáng sủa để sử dụng chủ đề địa phương. Chúng gây rắc rối cho các máy chủ không dựa trên khái niệm luồng và làm cho các ứng dụng lớn khó bảo trì hơn. Tuy nhiên, Flask chỉ không được thiết kế cho các ứng dụng lớn hoặc máy chủ không đồng bộ. Flask muốn làm cho nó nhanh chóng và dễ dàng để viết một ứng dụng web truyền thống.

Là vá một đối tượng toàn cầu với thông tin yêu cầu hiện tại là một mô hình chống?

Tôi tin là như vậy, bởi vì nó nằm trong quan điểm của máy phân tích mã tĩnh là trạng thái toàn cầu, mặc dù không phải vậy. Và tôi là một lập trình viên sẽ không hiểu nó hoạt động như thế nào nếu không đọc tài liệu một cách cẩn thận. Và điều này có hậu quả trên các bài kiểm tra .

Nó không phải là một thực hành tốt để chuyển yêu cầu như là một đối số cho quan điểm? Tôi nghĩ nó dễ đọc hơn, rõ ràng và dễ gỡ lỗi hơn. Và tránh nhà nước toàn cầu.

Nhiều khung web có cấu trúc tương tự: một yêu cầu toàn cầu. Theo một nghĩa nào đó, đó là điều đúng đắn bởi vì này, thực sự chỉ có một yêu cầu tại một thời điểm.

Vì vậy, có bất kỳ điểm nào trong việc chuyển yêu cầu xung quanh như là một tham số? Không. Yêu cầu là yêu cầu và các tham số được truyền vào những thứ khác nhau vào những thời điểm khác nhau.

Các thực vấn đề được đưa ra khi bạn bắt đầu để xem xét mức độ thấp hơn của một ứng dụng lớn hơn. Với một yêu cầu toàn cầu, có sự cám dỗ để viết mã ở khắp nơi truy cập yêu cầu trên toàn cầu. Đó là một điều rất xấu . Nó tạo ra sự ghép nối giữa các phần khác nhau của mã, làm cho nó khó thay đổi mọi thứ và làm cho nó khó kiểm tra mọi thứ.

Vì vậy, câu trả lời của tôi là: giữ yêu cầu toàn cầu và sống với nó. Tuy nhiên, bất cứ nơi nào một mô-đun hoặc chức năng riêng lẻ không cần toàn bộ yêu cầu, chỉ truyền dữ liệu cần thiết dưới dạng tham số. Chỉ chuyển tham chiếu, hoặc url hoặc đuôi lệnh và bất kỳ bit nào bạn cần vào các hàm của mình. Điều này sẽ giúp giữ mã theo mô-đun, giảm khớp nối và cải thiện khả năng kiểm tra.

Đối với các chương trình nhỏ, nó hầu như không quan trọng, nhưng đối với những chương trình lớn hơn thì đây có thể là một cứu cánh thực sự.

(Tôi sẽ trở nên táo bạo và biến điều này thành một câu trả lời, mặc dù tôi có thể nhận được một số ý kiến ​​trái chiều.)

Flask là một khung vi mô; bạn được hưởng lợi từ sự đơn giản trong khi từ bỏ diềm. Mặc dù ở mức độ ruột tôi đồng ý với bạn, tôi biết rằng tôi đã sử dụng bình + gunicorn tại một cửa hàng để cung cấp cho tôi đa luồng mà tôi cần. Nó hoạt động rất tốt. Mỗi phiên bản của tập lệnh chỉ đưa ra một yêu cầu (tức là một luồng) và gunicorn đã xử lý "quạt ra" giữa nhiều luồng. Thật tuyệt vời ở đó.

Vì vậy, nhược điểm mà bạn cảm nhận được - rằng nhiều luồng có thể tranh chấp trạng thái toàn cầu - không phải là vấn đề, bởi vì đó là một tập lệnh cho mỗi luồng.

(Đây là nơi tôi có thể gặp rắc rối) Việc xâu chuỗi và đồng thời chỉ khác nhau trong thế giới Python và nếu bạn đến với khung suy nghĩ Java, thật khó để hiểu được. được cấp trong Java hoặc được xử lý trong suốt bởi bộ chứa ứng dụng, gần với bề mặt của Python hơn rất nhiều.

Điều kỳ lạ đối với tôi là một luồng sẽ xử lý một lệnh gọi kịch bản của tôi, nhưng sau khi tôi có vài chục lần chạy trên một hộp cùng một lúc, tôi cảm thấy tốt hơn về nó.

Trong Python, bạn có printlệnh (hàm từ v3) in ra đầu ra tiêu chuẩn. Bạn không xác định rõ ràng rằng bạn muốn in thành STDOUT - hoàn thành cho bạn đằng sau hậu trường.

Ngẫu nhiên. Trong Python. Và không ai có vấn đề với điều đó. Tại sao?

printlà một phần của ngôn ngữ Python và một yêu cầu lập trình trong Python là ... biết ... biết Python. Và nếu bạn biết Python, bạn sẽ biết rằng printnhắm mục tiêu STDOUT. Không có bất ngờ ở đó.

Python - như một ngôn ngữ - có thể định nghĩa quy ước riêng của nó và cho rằng các lập trình viên nhận thức được chúng.

Các khung cũng được hưởng đặc quyền đó - đó là một trong những khác biệt chính giữa khung và thư viện. Bạn không phải học một thư viện để sử dụng nó - bạn chỉ cần tìm phần API mà bạn cần và giả sử nó tuân theo các quy ước của ngôn ngữ (hoặc khung). Đó là lý do tại sao bạn không thấy các nhà tuyển dụng đang tìm kiếm những người có kiến ​​thức về GSON hoặc Apache Commons. Nhưng bạn có thấy các nhà tuyển dụng đang tìm kiếm những người có kinh nghiệm với JQuery hoặc Ruby on Rails hoặc ASP.NET MVC - bởi vì đó là các khung xác định các quy ước riêng của họ mà bạn cần tìm hiểu và nhận thức được.

Flask, như một khung, có thể định nghĩa một quy ước để lưu trữ bối cảnh trong một luồng toàn cục cục bộ - và nó không gây ngạc nhiên cho bất kỳ ai, vì vậy đó không phải là một mô hình chống.