在這種情況下，我可以使用PRG以外的其他模式或方法嗎？

我不確定PRG模式在我的情況下是否正確。在我介紹我的情況下，PRG代表郵政/重定向/獲取，你可以在這裏讀了它： Wiki-article 在這種情況下，我可以使用PRG以外的其他模式或方法嗎？

我有一個搜索頁面，搜索與POST請求完成（並有很多的參數）。您通常搜索訂單，並且您可以搜索地址，日期，人員等。比方說你做了一個搜索，然後打開一個訂單。現在，如果你回去了，你的客戶會問你一個令人討厭的彈出窗口：「你想用它的參數重發請求嗎？」（或類似的東西）。

那個彈出的煩人，我不認爲我的客戶希望有吧:)

我在想，也許這將是很好的崗位參數存儲在會話中，提供了一個鏈接（所以你必須使用該鏈接，不能點擊，這使得存儲在會話這些參數新的post請求，並且不會有惱人的彈出式在你的客戶「回」）...

然後我搜索並找到PRG模式，這看起來很複雜，需要一些額外的編碼。我關心整個想法，爲什麼不讓整個搜索使用GET而不是POST。

所以我的這個問題/問題是問：

謝謝！

2011-09-20 Johannes

haha @「PRG代表Post/Redirect/Get」...我們知道:) – Rijk

-1：停止試圖讓你的問題適合一種模式 - 模式描述的代碼不反之亦然 – symcbean

我應該使用POST或GET我的搜索

GET，絕對。

PRG模式在這裏不適用。

2011-09-20 11:30:45

事實上，PRG是爲了防止重複表格提交。爲了搜索，請使用GET。這是查詢字符串的用途！ –

感謝你們兩位，努力使它GET而不是POST現在:) – Johannes

如果您希望共享最終的URI，並且/或儘可能簡潔，請使用PRG。如果您更關心性能，輕鬆閱讀代碼和開箱即用的解決方案 - 請使用GET。

谷歌使用GET舉例，並以一個非常醜陋的URI結束 - 但它工作並且速度很快。

如果你使用SESSION，你會佔用不必要的空間來保存它，並且你不能鏈接到結果，因爲URI不再代表頁面的階段，這是一件壞事。我會用PRG代替。

2011-09-20 11:30:06 chelmertz

回答