2010-02-09 24 views
51

Tôi chỉ đang xem xét chuyển đổi WebForms thành MVC:asp.net C# MVC: Làm thế nào để sống mà không có ViewState?

Trong .net MVC, khái niệm nào khiến ViewState trở thành thứ gì đó không cần thiết?

Nếu biểu mẫu được đăng lại trên chính nó, v.v ... (nghĩa là đăng lại)? trang/usercontrol duy trì trạng thái của nó như thế nào?

Những bí quyết nào mà mọi người đang làm để duy trì một số loại trạng thái chứ không phải đến trạng thái phiên?

Chắc chắn, một môi trường hoàn toàn không trạng thái không thể tồn tại?

+0

Tôi nhận ra trang web là không quốc tịch và tôi có ý nghĩa so với biểu mẫu web asp.net ... –

Trả lời

78

Nhưng tất nhiên là có thể. Trên thực tế, web không trạng thái. Bất kỳ suy nghĩ ngược lại là quang sai, trên thực tế.

Điều khiển web đã biến mất trong MVC. Không có sự kiện nào kích hoạt ở phía máy chủ. Điều này được thay thế bằng hai cơ chế khác nhau - URL và dữ liệu biểu mẫu POST. Việc sử dụng đúng cách chúng sẽ thay thế nhu cầu của bạn cho ViewState.

Trong ứng dụng web ASP.NET thông thường, bạn sẽ đặt một LinkButton trên trang web của bạn sẽ thực hiện chức năng X. ASP.NET sẽ dán rất nhiều ViewState cruft, javascript và các thứ khác vào trang web để khi người dùng nhấp vào nút và "đăng lại" cho trang web (bằng cách gửi biểu mẫu không ai biết), ASP.NET xây dựng lại những gì đã xảy ra và xác định một trình xử lý sự kiện nút cụ thể phải được thực hiện.

Trong MVC, bạn xây dựng liên kết của mình để truy cập một tuyến đường cụ thể. Tuyến đường mô tả những gì người dùng muốn thực hiện -/Users/Delinquent/Index (hiển thị danh sách tất cả những người dùng quá hạn). Hệ thống định tuyến trong MVC xác định Bộ điều khiển nào sẽ xử lý tuyến này và phương thức nào trên bộ điều khiển đó sẽ thực thi. Bất kỳ thông tin bổ sung nào cũng có thể được truyền tới phương thức điều khiển bằng các giá trị chuỗi truy vấn URL (? Trang = 5 cho trang thứ 5 của các tội phạm).

Ngoài các URL, bạn có thể sử dụng biểu mẫu HTML để đăng lại thông tin phức tạp hơn (chẳng hạn như giá trị của biểu mẫu) hoặc những thứ không phù hợp trong chuỗi truy vấn, chẳng hạn như tệp.

Vì vậy, bạn "duy trì" trạng thái thông qua chuỗi truy vấn và biểu mẫu giá trị POST. Bạn sẽ thấy rằng, trên thực tế, không có nhiều trạng thái để duy trì cuối cùng. Trong thực tế, phải duy trì rất nhiều trạng thái là một dấu hiệu tốt cho thấy thiết kế của bạn thiếu hoặc bạn đang cố gắng làm một cái gì đó không phù hợp với một mô hình trang web.

+11

Hoàn toàn đồng ý - nó không cần thiết, và, trong thực tế, dễ dàng hơn nhiều nếu không có nó. – Paddy

+7

Ít nhà nước trang web của bạn có dễ dàng hơn để mã và kiểm tra và duy trì. Vấn đề là trạng thái đó là một cái nạng khổng lồ có thể khó để loại bỏ nó lúc đầu. – Will

+8

+1 cho lớp xem không trạng thái như thiết kế tốt. Quan điểm không quốc tịch bị hiểu lầm rất nhiều. –

0

Trạng thái là mô hình nằm trong cơ sở dữ liệu. Bạn có thể cẩn thận lưu trữ cơ sở dữ liệu để giảm thời gian tải trang.

9

viewstate chỉ là một trường biểu mẫu ẩn lớn, xấu xí.

Viết ra các trường biểu mẫu ẩn của riêng bạn và mã hóa chúng nếu bạn có.

May mắn thay, không còn cách nào đơn giản để đổ rất nhiều dữ liệu vào trang, vì vậy bạn phải thận trọng về những gì bạn muốn lưu.

+6

được mã hóa? Nó không được mã hóa theo mặc định. Bạn có nghĩa là được mã hóa. Bạn có thể dễ dàng giải mã một khung nhìn. – Steven

+0

@ cho dù bạn nói đúng, nó không phải lúc nào cũng được mã hóa: http://msdn.microsoft.com/en-us/library/aa479501.aspx –

+0

Html.Serialize() –

0

Auto view tạo ra trạng thái không tồn tại trong MVC, nhưng bạn có thể viết đơn giản là sử dụng trường dữ liệu ẩn của riêng bạn,

Trong MVC bạn sẽ không thấy nhiều ký tự được mã hóa ở phía trên cùng của trang mà bạn don' t cần hầu hết trong số họ.

4

Nếu một biểu mẫu được đăng lại chính nó, vv (nghĩa là đăng lại)? trang /usercontrol duy trì trạng thái của nó như thế nào? Thủ thuật nào mà mọi người đang làm để duy trì một loại trạng thái nào đó và không phải là khu nghỉ dưỡng cho trạng thái phiên?

Đối tượng ViewData được đăng (hoặc đối tượng được nhập mạnh mẽ được ràng buộc với trang) có thể được đẩy ra chế độ xem lần nữa. Xem "Tích hợp Xác thực và Quy tắc Kinh doanh Logic với Lớp Mô hình" trong this page. Nó cho thấy cách bạn có thể đăng biểu mẫu, xác thực biểu mẫu và trả lại các trường quay lại biểu mẫu nếu xảy ra lỗi.

Trong .net MVC, khái niệm nào làm cho ViewState điều gì đó không phải là được yêu cầu?

Representational State Transfer (REST).

12

Một số câu hỏi liên quan:


Trong hầu hết các ngôn ngữ web truyền thống các khái niệm của một môi trường nhà nước thực sự là khá phổ biến. ASP.NET Webforms là một ngoại lệ cho quy tắc và nó tạo ra ngoại lệ đó bằng cách phát minh lại rất nhiều tiêu chuẩn. Mục tiêu đằng sau Webforms về cơ bản là trừu tượng hóa khái niệm về HTML và phát triển web nói chung để ranh giới giữa ứng dụng máy tính để bàn và ứng dụng web làm mờ đi từ quan điểm phát triển. Điều này thường có xu hướng có nghĩa là giải pháp mà ASP.NET Webform cung cấp, mặc dù hiệu quả, là một triển khai thực hiện tất cả các giao dịch kết quả trong một số đầu ra rất dài mà hoạt động tốt, đủ để thỏa mãn nhất. Ngược lại, lợi thế cốt lõi của ASP.NET MVC là nó cung cấp điều khiển đầu ra HTML cho nhà phát triển và cho phép họ tạo ra các ứng dụng web được cấu trúc mạnh mẽ, được thiết kế tốt hơn và sạch hơn trong việc triển khai và trình bày của họ. tiện.

Có thể cho rằng, một trong những hạn chế lớn nhất của mô hình Webform là ViewState vì nó cắt đầu ra, làm tăng kích thước trang một cách đáng kể trong các trường hợp nhất định và thường tương đương với việc sử dụng một cái búa để treo ảnh. Thay vì cố gắng sử dụng ViewState trong ứng dụng MVC của bạn (hoặc bất kỳ thứ gì tương tự), bạn nên bắt đầu sử dụng các mẫu kiểm soát rõ ràng các trường trong biểu mẫu của bạn và tối ưu hóa hoạt động đầu vào và đầu ra của bạn chỉ với dữ liệu có liên quan nhất. Ngoài các thay đổi trong đánh dấu, bạn cũng sẽ học cách xây dựng các giải pháp được thiết kế tốt hơn có thể được tiếp xúc trong ứng dụng của bạn và bên ngoài.

So sánh số một mà tôi muốn thực hiện đơn giản là: Webforms xây dựng trang Web, nhưng MVC xây dựng ứng dụng web. Nếu công việc hàng ngày của bạn chủ yếu là xây dựng các phần của trang web hoặc thêm các phần nhỏ của chức năng, bạn sẽ thường thấy Biểu mẫu web dễ dàng hơn và tốn ít thời gian hơn; mặt khác, nếu bạn muốn xây dựng một ứng dụng hoàn chỉnh có thể kiểm tra, có thể mở rộng và linh hoạt, MVC là cuộc gọi của bạn.

0

Thực tế là có. Bạn phải quên đi cách thức kiên trì được tạo ra với khung nhìn.

Bạn cũng phải chuyển đổi trong postback tâm trí của mình lên trang để "gọi tới bộ điều khiển". Bằng cách này mọi thứ sẽ dễ hiểu hơn sau đó.Thay vì gọi một trang, bạn đang gọi một bộ điều khiển trả về một khung nhìn. Vì vậy, hoặc bạn đang xây dựng toàn bộ "trang" của bạn một lần nữa trên mọi cuộc gọi hoặc bạn quyết định chỉ giải quyết những gì thực sự bị ảnh hưởng bởi hành động. Nếu nút đang thay đổi div, tại sao phải tải lại toàn bộ trang. Chỉ cần gọi cho bộ điều khiển của bạn và trả về dữ liệu mới trong div của bạn.

ví dụ chúng ta hãy tưởng tượng một kịch bản tổng thể/chi tiết:

<h2>Groups</h2> 
    <div id="GroupList"> 
    </div> 
    <div id="GroupDetail" title="Detail Group"> 
</div> 

Danh sách các nhóm được nạp một lần trong div và có là một cuộc gọi ajax thể một bộ điều khiển cho từng hạng mục của danh sách các nhóm :

<%= Ajax.ActionLink("Edit", "DetailLocalisationGroup", 
        new { id = group.Id }, 
        new AjaxOptions() { 
         UpdateTargetId = "DetailLocalisationGroup", 
         OnSuccess = "InitialisationDetailGroup" })%> 

gọi hành động này là DetailLocalisationGroup để nạp nhóm divDetail với html.

[AcceptVerbs("POST")] 
public ActionResult DetailLocalisationGroup(int id) 
{ 
    LocalisationGroup group = servicelocalisation.GetLocalisationGroup(id); 
    return View("DetailGroup", group); 
} 

Hiện tại có một biểu mẫu trong div và khi nhấn nút gửi của biểu mẫu này, chúng tôi chỉ gửi thông tin mà chúng tôi thực sự cần đến bộ điều khiển để lưu dữ liệu trong cơ sở dữ liệu.

Trong tất cả những sự kiện này, các GroupList tràn ngập những thứ mà được hiển thị trên màn hình của khách hàng, nhưng không có sự tương tác là cần thiết ở đó và vậy tại sao bận tâm chính mình với một ViewState cho những ...

+0

Xin chào, tôi sẽ đọc một số hướng dẫn và nghĩ rằng tôi hiểu những gì bạn đang nói ... tuy nhiên, bạn không thể liệt kê những thứ mà không có thiết kế bố cục Mẫu trên giao diện người dùng loại mẫu Html trong bộ điều khiển? Điều đó dường như không phải là một mối quan tâm tách biệt? –

+0

.. hoặc tôi đang thiếu một cái gì đó ... –

+0

Hy vọng nó không phải là quá muộn ... Vâng, bạn không cần mẫu Html trong bộ điều khiển. Điều duy nhất bạn cần là để nói xem nên sử dụng cái gì, và để cho cái nhìn này đối tượng, nó cần. Nó hoạt động theo cách tương tự như một điều khiển người dùng. – Arthis

3

MVC có một số lợi thế trên WebForms nhưng nó cũng có một số nhược điểm cũng như tôi đã trình bày chi tiết trong this answer. Tôi nghĩ rằng câu hỏi cơ bản mà bạn phải tự hỏi là liệu ViewState có phải là sự cố cho bạn bây giờ hay không và đó có phải là vấn đề mà bạn phải viết lại đơn đăng ký của mình không? Nếu không, sau đó học MVC là một mục tiêu xứng đáng (nó thực sự là khá mát mẻ) nhưng không phải là một mà tôi muốn mạo hiểm kinh doanh.

Với điều đó đang được nói, ViewState thực sự có thể bị tắt trong một số lượng lớn đáng ngạc nhiên các trường hợp. Nó được sử dụng chủ yếu để duy trì giá trị của các điều khiển thông qua một post-back. Vì vậy, ví dụ, nếu bạn có một hộp văn bản có giá trị bạn phải kiểm tra ở phía máy chủ cũng như một loạt các trường khác, ViewState sẽ cho phép bạn xử lý hậu tố, bắt lỗi (và hiển thị nhãn) và sau đó đưa người dùng trở lại biểu mẫu với tất cả các mục nhập của họ còn nguyên vẹn. Tuy nhiên, nếu một biểu mẫu là chỉ sẽ được điền và đăng lại và sau đó bạn sẽ chuyển hướng đến một trang khác, bạn có thể vô hiệu hóa nó một cách an toàn.

Cuối cùng, bạn hỏi mọi người đang làm gì để tránh trạng thái phiên. Có lý do nào để tránh trạng thái phiên không? Chắc chắn bạn không muốn nhiều thông tin ở đó nhưng tránh nó hoàn toàn là thực sự không cần thiết và, trên thực tế, sẽ chi phí cho bạn một trong những công cụ mạnh mẽ nhất trong kho vũ khí của bạn.

2

Hãy xem xét thực tế rằng chuyển động REST trong lập trình web được xác định dựa trên ý tưởng rằng trạng thái là xấu cho một chương trình. Wikipedia có mô tả phong nha với các tham chiếu: http://en.wikipedia.org/wiki/Representational_State_Transfer

Xuất phát từ tranditional ASP.NET và mô hình sự kiện phong phú mà nó cung cấp, MVC có thể khá mâu thuẫn. Nó hiện yêu cầu quản lý một số thứ chưa từng thấy trước đây, nhưng tôi nghĩ rằng giá trị về khả năng thử nghiệm (các trang REST có thể được kích hoạt dễ dàng mà không cần tạo một khung nhìn phức tạp và định nghĩa máy chủ không giữ trạng thái để tôi có thể kiểm tra một trang/tính năng trong sự cô lập) bù đắp đường cong học tập.

Đối với một số cuộc thảo luận về MVC trong ASP.NET và REST: http://blog.wekeroad.com/2007/12/06/aspnet-mvc-using-restful-architecture/

3

Tất cả các câu trả lời đều nói rằng ASP.NET MVC không sử dụng trạng thái là khá chính xác. Nhưng ASP.NET MVC thực tế sử dụng một số trạng thái, mặc dù nó không hoạt động như ViewState.

Thông thường, khi ai đó đăng dữ liệu lên ứng dụng của bạn, bạn sẽ muốn xác thực dữ liệu và hiển thị lỗi nếu dữ liệu không hợp lệ. Tuy nhiên, nếu bạn vừa trả lại trang chứa thông báo lỗi ngay lập tức, khi người dùng nhấn F5 để tải lại trang, dữ liệu sẽ được gửi lại. Điều này thường không phải là những gì bạn muốn. Vì vậy, khi bạn nhận ra rằng dữ liệu đã đăng ký không hợp lệ, bạn muốn yêu cầu người dùng GET trang (hoặc có thể là một trang khác) và hiển thị thông báo lỗi. Bạn làm điều đó bằng cách trả lại mã trạng thái chuyển hướng HTTP. Tuy nhiên, khi yêu cầu GET của người dùng đến, bạn biết thông báo lỗi nào sẽ hiển thị? Bạn sẽ phải bằng cách nào đó nhớ điều này từ khi bạn (máy chủ) đang xử lý POST cho đến khi bạn đang xử lý GET.

Để thực hiện việc này, bạn sử dụng tính năng ASP.NET MVC có tên là TempData. Điều này thực sự chỉ là một wrapper xung quanh Session mà đảm bảo rằng bất cứ điều gì bạn xô vào từ điển TempData sẽ ở đó cho đến khi yêu cầu tiếp theo và không còn.

+1

+1 bài đăng cũ không có "tôn giáo". Thật dễ dàng cho các chuyên gia của chúng tôi đăng ký một số mẫu uber - cho đến khi tất nhiên nó chạm vào ** người dùng **. Tôi rất muốn thấy một "ứng dụng phi trạng thái" có nghĩa là, sẽ ** hướng dẫn bạn qua ** thực hiện các khoản thuế của bạn. Đơn giản - làm thế nào về chỉ cần đi qua tùy biến một sản phẩm + quá trình kiểm tra và bất cứ điều hướng tồn tại ở giữa. – EdSF

0

Bạn có thể bắt chước trạng thái xem với MVC3Futures project. Nó sẽ lưu toàn bộ mô hình trong chế độ xem.

Tất cả những gì bạn phải làm là sắp xếp lại mô hình và mã hóa nó trong chế độ xem.

@Html.Serialize("Transfer", Model, SerializationMode.EncryptedAndSigned) 

Và trong bộ điều khiển thêm thuộc tính deserialized.

public ActionResult Transfer(string id,[Deserialize(SerializationMode.EncryptedAndSigned)]Transfer transfer) 
0

Sau khi đọc tất cả những bài viết, có vẻ như MVC là không tốt cho LOB loại ứng dụng, nơi bạn sẽ có rất nhiều điều khiển và hoạt động CRUD và bạn muốn duy trì trạng thái các nút điều khiển. Có rất nhiều lý do bạn muốn người dùng ở trên cùng một chế độ xem & duy trì trạng thái sau khi thực hiện các thao tác gửi. Ví dụ để hiển thị lỗi, thông báo xác thực phía máy chủ, thông báo thành công hoặc để thực hiện bất kỳ hành động nào khác. chuyển hướng người dùng đến một số chế độ xem khác để hiển thị các thông báo này là không thực tế.

0

Bạn có thể lưu trữ bất kỳ đối tượng nào trong trạng thái phiên.

HttpContext.Session["userType"] = CurrentUser.GetUserType(); 
Các vấn đề liên quan