Tại sao bạn sẽ sử dụng MVC trên Web Forms?

Gần đây, một kiến ​​trúc sư đã mô tả công ty của chúng tôi cung cấp giải pháp Rolls-Royce (MVC) khi tất cả những gì anh ta cần là một chiếc Toyota (Web Forms).

Tôi tò mò muốn tìm hiểu những gì bạn nghĩ về các hình thức web so với MVC như là một lựa chọn kiến ​​trúc.

Sự tương tự của Rolls-Royce / Toyota là rất thiếu sót và sai lệch. Một (ASP.NET MVC) không chỉ đơn giản là một phiên bản đắt hơn hoặc đắt hơn của phiên bản kia (ASP.NET WebForms). Chúng là những cách tiếp cận rất khác nhau để xây dựng các ứng dụng web bằng ASP.NET.

Đối với tôi, sự khác biệt lớn nhất về kiến ​​trúc giữa MVC và WebForms là cách chúng hoạt động với môi trường không trạng thái của web: WebForms làm việc chăm chỉ để xây dựng một tập hợp trừu tượng che giấu bản chất phi trạng thái của lập trình web, trong khi MVC ôm lấy môi trường phi trạng thái và hoạt động với nó

Mỗi cách tiếp cận đều có lợi ích và bất lợi của nó, nhưng tôi thực sự thích cách xây dựng các trang web với MVC cảm thấy tự nhiên hơn nhiều so với WebForms (với lớp của nó trên lớp trừu tượng bị rò rỉ ).

Câu hỏi cũ nhưng nó xứng đáng có một câu trả lời chi tiết hơn trong trường hợp bất kỳ ai khác ngoài đó vẫn thực sự có một vấn đề nan giải về nó.

Cuối cùng, biểu mẫu web là một giải pháp ứng dụng khách mỏng, điều đó có nghĩa là bạn nhấn một loạt các nút đẹp và công cụ giao diện người dùng (máy khách) được tạo cho bạn. Nếu bạn có những người biết cách tạo ra nó trong các biểu mẫu web và hoàn toàn không có mối quan tâm về khả năng bảo trì / sửa đổi và trang web này hoàn toàn ngắn hạn và dùng một lần, thì không có gì sai với phương pháp này. Có thể tìm hiểu cách thực hiện công cụ của riêng bạn nhưng trong trường hợp này, bạn cần phải biết cả các biểu mẫu web của nội dung web cố gắng bảo vệ các nhà phát triển ứng dụng .NET khỏi và tất cả các công cụ định dạng web khiến hầu hết các nhà phát triển web phía khách muốn giết Microsoft kỹ sư chịu trách nhiệm.

Trong 99,5% của tất cả các tình huống sử dụng khác, chúng tôi đã ngừng cố gắng ẩn web khỏi các nhà phát triển ứng dụng vì thực sự, nếu bạn muốn viết ứng dụng web, bạn thực sự nên học cách hoạt động của web. Điều trớ trêu của các giải pháp khách hàng dày và mỏng là chắc chắn phương pháp tiếp cận khách hàng mỏng chắc chắn sẽ làm hỏng những thứ nhảm nhí ra khỏi mặt trước của bạn và không có gì khác ngoài hiệu suất. Quan trọng hơn, các giải pháp này luôn khiến mọi thứ trở nên không linh hoạt như mọi địa ngục đối với những người thực sự biết họ đang làm gì và không muốn bị hạn chế bởi khuôn khổ có hiệu lực.

Không có gì quá vô nghĩa khi bắt ai đó biết mọi thứ về CSS, JavaScript, HTML, XHR và khiến chúng hoàn toàn vô dụng bằng cách chặn đường họ từng bước với một khuôn khổ ...

• Xóa tất cả các thẻ tập lệnh 'không cần thiết' trong các thẻ đầu để giữ cho bạn không bị phụ thuộc vào tập lệnh. (tốt hơn là để một 'người quản lý kịch bản' xử lý việc đó cho bạn) Được cấp, hiện tại không ai đưa họ lên đó nếu họ biết họ đang làm gì nhưng điều đó chỉ gây rối.

• Khăng khăng bạn bọc tất cả các HTML trong một thẻ mẫu đơn. HTML không cho phép các biểu mẫu bên trong các biểu mẫu để bạn thực hiện các biểu mẫu web theo cách hoặc không có cách nào cả.

• Tạo ra một "vòng đời" gồm 18 bước cho những gì thực sự cần phải phản ứng với các sự kiện UI bằng cách tương tác với trình duyệt để gửi tin nhắn đến máy chủ và sau đó phản ứng khi máy chủ phản hồi. Tóm tắt quá trình đó với một đống rác khổng lồ không bao giờ cần phải xảy ra (và công bằng mà nói, MS không phải là kẻ ngốc duy nhất cố gắng làm điều này).

• Trên thực tế, mọi thứ có thể có thể có được trong cách sử dụng các giải pháp phi webforms cho các vấn đề. Ví dụ: Khi tôi còn là một khách hàng nhỏ tuổi hơn, tôi đã dành cả ngày để tìm cách tạo nút gửi ở đầu trang kích hoạt nút gửi ở cuối trang (Tôi giả sử là do một trang lớn đó điều khổng lồ). Thông thường, việc này sẽ mất 5 phút nhưng sau một vài giờ thiết kế ngược lại các JavaScript dạng web chịu trách nhiệm, tôi phát hiện ra rằng chúng nằm trong số những thứ khác mà tôi không biết về thời điểm đó cho bạn biết yếu tố hình thức cuối cùng là gì trọng tâm là để khi nhấp vào nút gửi, chỉ có nút Microsoft Gửi (tm) chính thức sẽ hoạt động liên quan đến việc kích hoạt trình xử lý Microsoft Gửi (tm) chính thức.

Vì vậy, không, Rolls-Royce vs Toyota, là hoàn toàn không hợp lý. Tôi sẽ nói nhiều hơn, một chiếc Hyundai hoàn toàn hợp lý mà bạn phải trả quá nhiều so với một chiếc Pinto được Microsoft thiết kế với hệ thống trên tàu tự động quay 90 độ khi phát hiện ra bạn đã mua xăng hoặc dầu từ ai đó ngoài Microsoft và nó đã phát hiện ra tường thuận tiện để đâm vào. Một chiếc xe lý tưởng cho người lái xe trung thành với thương hiệu tự tử, không biết gì về web và muốn thề trung thành trọn đời với Microsoft.

Tất cả .NET MVC thực sự là, đơn giản và hợp lý, và nó không phát minh lại lớp của chính nó để vỗ lên trên web. Nó chỉ hoạt động với những gì ở đó để giúp loại bỏ một số nồi hơi cho bạn. Có sẵn các khung công tác tốt hơn / rẻ hơn / miễn phí nhưng nếu bạn đã tự khóa mình vào điều .NET, bạn có thể làm điều tồi tệ hơn nhiều.

Nhưng nghiêm túc, hãy tránh xa! @ # $ Khỏi các biểu mẫu web. Bây giờ nó gần như đã chết. Để nó đi. Nói với khách hàng của bạn rằng bạn sẽ làm điều đó với số tiền gấp ba lần nếu họ cũng hứa với bạn một hợp đồng hỗ trợ hàng giờ độc quyền và sinh lợi khi họ thực sự muốn làm điều gì đó mới hoặc khác biệt hoặc khi crap bắt đầu phá vỡ vì thậm chí MS không thể bị làm phiền khi tiếp tục thêm vào tập tin đó của tệp ajax.js 10.000 dòng mà họ rút ra khỏi ass DLL của mình, nơi bạn không thể chạm vào nó.

Một giải pháp ASP.NET MVC không cần phải phức tạp hơn giải pháp WebForms. Cá nhân, tôi thấy ASP.NET MVC thực sự đơn giản hơn WebForms rất nhiều và dường như nó chắc chắn sẽ sạch hơn.

Từ kinh nghiệm của tôi, rất nhiều khung công tác MVC (ASP.NET, Rails, CodeIgniter, v.v.) có nhiều chức năng và quy ước cốt lõi giống nhau. WebForms thực sự là con vịt kỳ lạ từ góc độ web. Tôi đoán là hầu hết các lập trình viên web sẽ nhanh hơn trong việc chọn ASP.NET MVC so với WebForms.

Lý do hàng đầu bạn sẽ sử dụng ASP.NET MVC trên ASP.NET WebForms là khả năng kiểm tra. Chắc chắn bạn có thể kiểm tra đơn vị WebForms nhưng điều này đòi hỏi phải có các khung mô phỏng và rất nhiều đau đớn. Lý do thứ hai là MVC làm cho việc phân tách các mối quan tâm trở nên dễ dàng hơn một chút . Điều này có thể cung cấp rất nhiều mã tái sử dụng và làm cho mã của bạn được ghép lỏng lẻo. Điều này không có nghĩa là không thể làm điều tương tự trong ASP.NET với các mẫu như MVP.

Nhược điểm của MVC là bạn mất rất nhiều chức năng và đã được tích hợp vào WebForms trong thập kỷ qua (gần như). MVC đã đi một chặng đường dài kể từ khi thành lập để cung cấp các tính năng tương tự.

Về hiệu suất, có ai có bằng chứng bằng cách này hay cách khác trong đó công nghệ "nhanh hơn" không?

Tôi không nghĩ cái này tốt hơn cái kia. Tôi thực sự thích khung MVC và đã sử dụng nó rất thành công nhưng tôi luôn đảm bảo rằng tôi chọn công nghệ phù hợp với dự án.