ASP.NET MVC - TempData - Thực hành tốt hoặc xấu

Tôi đang sử dụng AcceptVerbsphương pháp được nêu chi tiết trong bài đăng trên blog Xem trước 5 của Scott Gu để xử lý các mục nhập biểu mẫu trong ASP.NET MVC:

• Người dùng nhận được một biểu mẫu trống thông qua GET
• Người dùng đăng biểu mẫu đã điền qua ĐĂNG cho cùng một Hành động
• Hành động xác thực dữ liệu, thực hiện hành động thích hợp và chuyển hướng đến chế độ xem mới

Vì vậy, tôi không phải sử dụng TempData. Điều đó nói rằng, bây giờ tôi phải thêm bước 'xác nhận' vào quy trình này và có vẻ như nó yêu cầu sử dụng TempData.

Vì lý do nào đó, tôi có ác cảm với việc sử dụng TempData- rằng nó là thứ cần được thiết kế xung quanh.

Đây có phải là một mối quan tâm hợp lệ hay tôi đang bịa ra?

Tôi nghĩ về dữ liệu tạm thời là một cơ chế ghi và quên để thông báo cho người dùng. Thật tuyệt khi cung cấp cho họ một lời nhắc nhở về điều gì đó họ đã làm gần đây, nhưng tôi cũng sẽ do dự khi đặt nó thành một bước bắt buộc trong một số quy trình của người dùng. Lý do là nếu họ làm mới trang, tôi tin rằng nó sẽ biến mất. Tôi đoán tôi cũng do dự khi sử dụng nó vì nó không thực sự được xác định rõ ràng về độ tin cậy của nó.

Tôi tự hỏi nếu vấn đề là bạn đang chuyển hướng hành động đến một trang khác trước bước xác nhận. Tôi tự hỏi liệu thay vào đó sau khi họ gửi lần đầu tiên, bạn có thể thực hiện đủ quá trình xử lý để tạo hộp thoại xác nhận, sau đó trả lại trang ban đầu với câu hỏi xác nhận hay không. Tương tự như cách bạn có thể thực hiện xác thực, ngoại trừ quy tắc xác thực kiểm tra xem bước xác nhận có được thực hiện hay không (với giao diện người dùng xác nhận bị ẩn cho đến khi quá trình xác thực khác vượt qua).

Không cần phải có ác cảm với TempData ... Nhưng nếu không được sử dụng đúng cách, nó chắc chắn có thể là một dấu hiệu của thiết kế kém. Nếu bạn đang sử dụng RESTful URL, TempData là phương pháp hay nhất để chuyển các thông báo từ Hành động POST sang Hành động GET của bạn. Xem xét điều này:

Bạn có một biểu mẫu tại URL Sản phẩm / Mới. Biểu mẫu Đăng lên Sản phẩm / Tạo, xác thực biểu mẫu và tạo Sản phẩm, Khi Thành công, Bộ điều khiển chuyển hướng đến URL Sản phẩm / 1 và nếu có lỗi sẽ chuyển hướng trở lại sản phẩm / Mới để hiển thị Thông báo Lỗi.

Products / 1 chỉ là hành động GET tiêu chuẩn cho sản phẩm, nhưng chúng tôi muốn một thông báo hiển thị cho biết việc chèn đã thành công. TempData là hoàn hảo cho việc này. Thêm thông báo vào TempData trong Bộ điều khiển bài đăng và đặt một số if logic trong chế độ xem và bạn đã hoàn thành.

Khi thất bại, tôi đã thêm các giá trị đã nhập trong formCollection và một tập hợp các Thông báo lỗi vào TempData trong Post Action, và chuyển hướng đến các Action Prodcuts / New. Tôi đã thêm logic vào dạng xem để điền các đầu vào biểu mẫu với các giá trị đã nhập trước đó cùng với bất kỳ thông báo lỗi nào. Có vẻ đẹp và sạch sẽ đối với tôi!

Tôi nghĩ rằng bạn nên do dự trước khi sử dụng TempData. TempData được lưu trữ trong phiên và điều này có thể có ý nghĩa đối với bạn nếu:

1. Bạn không sử dụng phiên trên trang web của mình ngay bây giờ
2. Bạn có một hệ thống cần mở rộng quy mô đến thông lượng cao, tức là bạn muốn tránh hoàn toàn trạng thái phiên
3. Bạn không muốn sử dụng cookie (tôi không biết MVC hỗ trợ các phiên không có nấu ăn ngay bây giờ tốt như thế nào)

Nếu trang web của bạn cần có tính khả dụng cao, thì có những cân nhắc bổ sung xung quanh việc áp dụng trạng thái phiên nhưng đây đều là những vấn đề có thể giải quyết được.

Tôi có một phương thức GetModel kiểm tra TempData ["model"] trước và trả về phương thức đó. Nếu không thì GetModel tải dữ liệu thích hợp từ cơ sở dữ liệu.

Nó tiết kiệm thêm tải từ cơ sở dữ liệu khi tôi có một hành động cần trả lại một dạng xem khác yêu cầu cùng một dữ liệu mô hình.

Kiểm tra bộ điều khiển không phiên trong MVC3. Hóa ra, việc sử dụng phiên ngăn cản việc thực hiện song song các yêu cầu của một người dùng và do đó dẫn đến hiệu suất bị giảm sút.

Vì tempdata sử dụng phiên theo mặc định nên bạn sẽ không thể sử dụng tính năng này. Bạn có thể chuyển sang sử dụng cookie cho tempdata, nhưng nó hơi khó xử (ít nhất là đối với tôi). Tuy nhiên, vẫn sạch hơn so với viewstate, vì vậy có lẽ nó không phải là một công cụ phá vỡ vấn đề lớn như vậy.

Tại sao bạn lại có ác cảm như vậy? Điều này chỉ đơn giản là làm cho công việc của nó và làm cho nó tốt :)

Nếu bạn không thích nó vì nó không được gõ mạnh, bạn luôn có thể tạo một trình bao bọc xung quanh để cung cấp cho bạn giao diện được gõ mạnh.

Nó giống như sử dụng ViewData, có nghĩa là nó có thể không phải là một rủi ro bảo mật. Nhưng tôi muốn sử dụng ViewData hơn là TempData. Kiểm tra tại đây để biết so sánh: http://www.squaredroot.com/2007/12/20/mvc-viewdata-vs-tempdata/

Tùy thuộc vào thiết kế, bạn luôn có thể lưu trữ người dùng / giỏ hàng hoặc bất kỳ thứ gì bạn cần trong dữ liệu tạm thời trong cơ sở dữ liệu và chỉ có trường "IsReady" cho biết liệu nó đã hoàn thành hay chưa, giúp nó có thể mở rộng để sử dụng sau này nếu bạn muốn sử dụng nhớ rằng mọi người có thể đóng trình duyệt của họ.

Tất cả các câu trả lời tốt, bạn đã xem này để chuyển thông điệp cùng.

TempData và Session không phải là ý tưởng tốt nhất cho kiến ​​trúc RESTful vì hầu hết các phiên được lưu trữ trong bộ nhớ. Vì vậy, khi bạn muốn sử dụng một máy chủ, phiên người dùng sẽ tồn tại trên một máy chủ trong khi yêu cầu tiếp theo của họ có thể được gửi đến một máy chủ khác.

Điều đó đang được nói, hãy xem cách sử dụng TempData này để chuyển các thông điệp ở đây.

http://jameschambers.com/2014/06/day-14-bootstrap-alerts-and-mvc-framework-tempdata/

Mabye điều này có thể được điều chỉnh để sử dụng cách tiếp cận chuỗi truy vấn nếu chỉ được sử dụng để chuyển hướng đến cảnh báo trang khác.