Có một số điều tôi không thể làm với ASP.NET MVC? Những điều chỉ có thể thực hiện với ASP.NET WebForms, hoặc cực kỳ dễ dàng hơn nhiều với WebForms?Những điều tôi không thể làm trong ASP.NET MVC
Chúng tôi xem xét sử dụng ASP.NET MVC cho dự án mới. Nhưng tôi tự hỏi nếu có một số điều rõ ràng, chúng tôi sẽ không thể làm với ASP.NET MVC khi so sánh với WebForms, hoặc những nơi mà chúng tôi sẽ phải dành nhiều thời gian với ASP.NET MVC.
Điều quan trọng nhất là sử dụng các kiểm soát của bên thứ ba hiện có trên biểu mẫu của bạn. Hầu hết các điều khiển sẵn có khá dễ tái sản xuất, nhưng nếu bạn có quyền kiểm soát của bên thứ 3, bạn có thể phải lưu trữ trên trang aspx thông thường (không phải MVC) (luckliy được hỗ trợ).
Tương tự như vậy, "bộ phận web"
Ngoài ra - các tính năng mà ASP.NET sử dụng html khác nhau cho khách hàng khác nhau (di động, vv) trở thành ... khác nhau; bạn sẽ không muốn làm điều này bằng tay, nhưng trong thực tế hầu hết các khách hàng bây giờ làm việc với html tiêu chuẩn, do đó, nó là ít của một vấn đề ở nơi đầu tiên.
Một số thứ như i18n qua tệp resx cần thêm công việc hơn là trong mẫu vanilla MVC, nhưng các mẫu có trên internet.
Một điểm ... MVC chỉ được cấp phép cho MS/ASP.NET; vì vậy một điều bạn không thể làm (mà không vi phạm các điều khoản, như tôi hiểu nó) là để chạy nó trong mono/Apache - nhưng IANAL.
Bây giờ xem xét những điều bạn có thể làm với MVC, mà bạn không thể (hoặc rất khó) với vani:
lại độ phân giải đầu vào:
public ActionResult Show(string name, int? page, int? pageSize) {...}
sẽ chọn "tên", "trang" và "trang Kích thước "tắt (bất kỳ) tuyến đường, chuỗi truy vấn hoặc biểu mẫu - vì vậy bạn không phải mất nhiều thời gian để chọn các giá trị yêu cầu.
mẫu lại - aspx/ascx không phải là tùy chọn tạo khuôn mẫu duy nhất. Ví dụ: xem here; hoặc bạn có thể viết của riêng bạn nếu bạn thích ... Khung nhìn không gắn với điều khiển ASP.NET tại tất cả.
Tôi nghĩ trạng thái xem không tồn tại trong MVC. Bạn sẽ phải theo dõi trạng thái xem của riêng mình theo một cách nào đó khác với trạng thái xem được xây dựng trong các dự án không phải MVC.
EDIT: Theo nhận xét: "Loại bỏ ViewState là một lợi thế không phải là bất lợi". - Craig
MVC có bộ sưu tập khóa/giá trị ViewData vẫn tồn tại trên các bài đăng để duy trì trạng thái. Bộ sưu tập TempData cũng được sử dụng cho các thay đổi trạng thái một lần: ví dụ: thông báo trạng thái "hồ sơ này đã bị xóa" –
ViewState là một phần của mô hình postback WebForms và không sử dụng trong MVC, giống như cách nó không được sử dụng với PHP hoặc Python. Loại bỏ ViewState là một lợi thế không phải là một bất lợi. – Craig
+1 cho Craig.Viewstate là tốt nhất chỉ là một điều bình thường, và trong những tình huống tồi tệ nhất đó là một sự ghê tởm hoàn toàn. Tốt hơn là chúng ta nên loại bỏ nó. – Kibbee
Điều lớn nhất là Kiểm soát. Điều khiển người dùng không có sẵn với ASP.NET MVC. Tôi thậm chí đã đi xa đến mức thử sử dụng mã như sau:
new Label().RenderControl(...ResponseStream...);
Không súc sắc.
Tất nhiên, như một phần của điều đó, không cần thiết phải xem trạng thái, do đó không có trong đó. Tuy nhiên,
Điều khiển máy chủ hoạt động.
Trong khi thực sự, bạn có thể sử dụng một phần lượt xem cho một cái gì đó tương tự –
điều này là do thiết kế: cách tiếp cận MVC cố gắng để tạo ra sự đơn giản và kiểm soát tốt hơn chính xác những gì đánh dấu được hiển thị –
MVC không có điều khiển người dùng, nó không có các điều khiển máy chủ khi chúng được thiết kế để đi với mô hình WebForms. Bởi vì MVC không có nghĩa là drag'n'drop trực quan, nên việc phát triển kiểu điều khiển sự kiện không cần thiết. Nó không phải là một sự giám sát, nó là một quyết định thiết kế. – Craig
Như Marc đã nói, các công cụ của bên thứ ba và (serverside) không thể sử dụng. Vì vậy, tát một cái gì đó với nhau một cách nhanh chóng bằng cách kéo và thả một vài điều khiển trên một hình thức (như một mạng lưới và một điều khiển truy cập dữ liệu) không còn là một lựa chọn.
Nhưng với quá trình codegeneration, bạn vẫn có thể thực hiện điều gì đó nhanh chóng. Và bạn vẫn có tùy chọn ở trên nếu bạn cần một cái gì đó nhanh chóng.
Xác thực không dễ dàng như trong WebForms. Trong các biểu mẫu web, bạn có thể thêm trình xác thực và chỉ cần đặt thuộc tính cho phép xác thực khách hàng. Bạn có thể bản địa hóa lỗi. Nội địa hóa hoạt động với clientide và serverside.
Không có xác nhận của khách hàng trong hộp trong MVC và bạn cần tìm cách để bản địa hóa các lỗi không mong muốn của khách hàng.
Bản địa hóa bản thân khác. Ressources rõ ràng theo mặc định không tồn tại trên mỗi trang, bởi vì không có trang. Nhưng có một cách tốt để có tài nguyên mỗi lượt xem.
Tôi vẫn không kiểm tra, nếu có thể đặt yêu cầu SSL cho mỗi thư mục.
EDIT
Câu chuyện là khác nhau với MVC3. Hiện có một sự hỗ trợ xác nhận tốt.
Vẫn còn những thứ không được triển khai trong MVC. Vấn đề lớn nhất đối với tôi là hoàn thành việc thực hiện cho việc thanh toán tiền mặt và thanh toán một phần tiền mặt. Có một số cải tiến trong MVC3 trong lĩnh vực này nhưng vẫn chưa hoàn chỉnh. Dù sao hãy theo dõi: các đội MVC có thể biết rằng đây là điều họ nên làm.
Cảm ơn các ý kiến. Liên quan đến xác nhận serverside/clientside, tôi tìm thấy xval (http://xval.codeplex.com) mà dường như cung cấp một giải pháp cho rằng ... –
Xác nhận đã được cải thiện nhiều trong MVC2 –
.. và hơn nữa trong MVC3 –
ASP.NET Ajax không hoạt động với ASP.NET MVC do đó không có UpdatePanel (do thiếu đăng lại). May mắn thay có tích hợp ajax (Ajax.Form) có thể được sử dụng để thực hiện các cập nhật từng phần không đề cập đến jQuery được chuyển theo mặc định với mẫu dự án Visual Studio.
Cảm ơn bạn đã trả lời tốt đẹp, điều đó làm cho tôi chắc chắn rằng nó tương đối an toàn để đi cho mvc. Tuy nhiên, tôi không hiểu những gì đằng sau điểm của bạn với 'độ phân giải đầu vào tự động', 'IoC/DI' và 'nhiều tùy chọn tạo khuôn mẫu'. Bạn đã có một số ví dụ về những gì bạn có nghĩa là do đó? –
được cập nhật cho mỗi câu hỏi –
ASP.Net MVC là nguồn mở theo MS-PL, đây là một giấy phép rất tự do, xem http://weblogs.asp.net/scottgu/archive/2009/04/01/asp-net- mvc-1-0.aspx. Nó hoàn toàn hợp pháp để chạy dưới mono. – jeroenh