Khi nào nên ưu tiên ASP.NET WebForms hơn MVC

Tôi biết rằng Microsoft đã nói

ASP.NET MVC không phải là sự thay thế cho WebForms.

Và một số nhà phát triển cho biết WebForms phát triển nhanh hơn MVC. Nhưng tôi tin rằng tốc độ mã hóa giảm xuống mức thoải mái với công nghệ nên tôi không muốn có bất kỳ câu trả lời nào trong đó.

Vì ASP.NET MVC cung cấp cho nhà phát triển nhiều quyền kiểm soát hơn đối với ứng dụng của họ, tại sao WebForms không bị coi là lỗi thời? Ngoài ra, khi nào tôi nên ưu tiên WebForms hơn MVC để phát triển mới?

Webforms so với MVC dường như là một chủ đề nóng ngay bây giờ. Tất cả mọi người tôi biết chào hàng MVC là điều tuyệt vời tiếp theo. Từ sự hiểu biết nhỏ nhoi của tôi trong đó, có vẻ ổn, nhưng không, tôi không nghĩ nó sẽ là sự kết thúc của các biểu mẫu web.

Lý luận của tôi và lý do tại sao các hình thức web sẽ được chọn trên MVC, có liên quan nhiều đến quan điểm kinh doanh hơn là cái nào tốt hơn cái kia.

Thời gian / tiền bạc là lý do lớn nhất tại sao các biểu mẫu web sẽ được chọn trên MVC.

Nếu hầu hết nhóm của bạn biết biểu mẫu web và bạn không có thời gian để tăng tốc độ trên MVC, mã sẽ được tạo ra có thể không chất lượng. Học những điều cơ bản của MVC sau đó nhảy vào và thực hiện trang phức tạp mà bạn cần làm là những điều rất khác nhau. Đường cong học tập cao nên bạn cần tính đến yếu tố đó vào ngân sách của mình.

Nếu bạn có một trang web lớn được viết tất cả bằng các biểu mẫu web, bạn có thể có xu hướng tạo bất kỳ trang mới nào trong biểu mẫu web để bạn không có hai loại trang rất khác nhau trong trang web của mình.

Tôi không nói rằng đó là một cách tiếp cận tất cả hoặc không có gì ở đây, nhưng nó làm cho mã của bạn khó bảo trì hơn nếu có sự phân chia của cả hai, đặc biệt là nếu không phải mọi người trong nhóm đều quen thuộc với MVC.

Công ty của tôi gần đây đã làm ba trang thử nghiệm với MVC. Chúng tôi ngồi xuống và thiết kế chúng ra. Một vấn đề chúng tôi gặp phải là hầu hết các màn hình của chúng tôi đều có chức năng Xem và Chỉnh sửa trên cùng một trang. Chúng tôi cuối cùng cần nhiều hơn một hình thức trên trang. Không có vấn đề gì, ngoại trừ sau đó chúng tôi sẽ không sử dụng trang chủ của chúng tôi. Chúng tôi đã phải sửa đổi lại để cả trang web và trang MVC có thể sử dụng cùng một trang chủ cho giao diện chung. Bây giờ chúng ta có thêm một lớp lồng.

Chúng tôi cần tạo một cấu trúc thư mục hoàn toàn mới cho các trang này để nó tuân theo sự phân tách MVC thích hợp.

Tôi cảm thấy có quá nhiều tệp cho 3 trang, nhưng đó là ý kiến ​​cá nhân của tôi.

Theo tôi, bạn sẽ chọn các biểu mẫu web trên MVC nếu bạn không có thời gian / tiền để đầu tư vào việc cập nhật trang web của mình để sử dụng MVC. Nếu bạn thực hiện một cách tiếp cận nửa vời cho việc này, nó sẽ không tốt hơn so với các biểu mẫu web bạn có bây giờ. Tồi tệ hơn, bạn thậm chí có thể thiết lập công nghệ này cho sự thất bại trong công ty của mình nếu nó bị rối, vì quản lý cấp trên có thể coi nó là một thứ gì đó kém hơn những gì họ biết.

Tôi đã phát triển các ứng dụng ASP .Net WebForms trong 3 năm và sau một ngày thực hiện một hướng dẫn MVC, tôi đã được bán. MVC gần như LUÔN là giải pháp tốt hơn. Tại sao?

• Vòng đời trang đơn giản và hiệu quả hơn
• Không có thứ gọi là điều khiển ngoài các điều khiển html. Bạn không cần gỡ lỗi đầu ra của mình để xem ASP .Net đang tạo ra cái gì.
• ViewModels cung cấp cho bạn sức mạnh to lớn và làm giảm nhu cầu thực hiện ràng buộc điều khiển thủ công và nó giúp loại bỏ nhiều lỗi liên quan đến ràng buộc.
• Bạn có thể có nhiều hình thức trên một trang. Đây là một hạn chế nghiêm trọng của WebForms.
• Web không trạng thái và MVC phù hợp với kiến ​​trúc của web chặt chẽ hơn. Webforms giới thiệu trạng thái và các lỗi bạn gặp phải bằng cách giới thiệu ViewState. ViewState là tự động và hoạt động ở chế độ nền, vì vậy nó không phải lúc nào cũng hoạt động theo cách bạn muốn.
• Các ứng dụng web cần phải làm việc với ajax những ngày này. Không thể chấp nhận tải toàn bộ trang nữa. MVC làm cho ajax trở nên tốt hơn, dễ dàng hơn và hiệu quả hơn với JQuery.
• Vì bạn có thể có nhiều biểu mẫu trên một trang và do kiến ​​trúc được điều khiển bởi các lệnh gọi tới url, bạn có thể thực hiện những điều thú vị như ajax tải một biểu mẫu khác, như biểu mẫu chỉnh sửa vào trang hiện tại của bạn bằng JQuery. Một khi bạn nhận ra điều này cho phép bạn làm, bạn có thể làm những điều tuyệt vời một cách dễ dàng.
• ASP .Net WebForms không chỉ là một bản tóm tắt trên html, nó là một thứ cực kỳ phức tạp. Đôi khi bạn sẽ nhận được một lỗi kỳ lạ và đấu tranh với nó lâu hơn cần thiết. Trong nhiều trường hợp, bạn thực sự có thể thấy những gì nó đã làm sai nhưng bạn không thể làm bất cứ điều gì về nó. Bạn cuối cùng làm cách giải quyết kỳ lạ.
• WebForms không tạo ra một công nghệ tốt cho các nhà thiết kế. Các nhà thiết kế thường thích làm việc với html trực tiếp. Trong MVC nó là một khung nhìn, trong WebForms là nửa ngày làm việc.
• Vì nền tảng web đang phát triển nhanh, WebForms sẽ không theo kịp. Bạn không biết các thẻ hoặc tính năng mới của HTML5, nó vẫn sẽ hiển thị cùng một nội dung trừ khi bạn nhận được (thường) các điều khiển bên thứ 3 đắt tiền hoặc chờ Microsoft phát hành bản cập nhật.
• Các điều khiển trong WebForms giới hạn bạn theo nhiều cách. Trong MVC, bạn có thể lấy một thư viện JQuery và tích hợp nó vào các mẫu của bạn.

Tôi biết một số vấn đề ở trên đã được giải quyết ở một mức độ nào đó khi WebForms phát triển, nhưng đó là kinh nghiệm ban đầu của tôi. Nói chung, tôi sẽ rất khó tìm thấy một trường hợp kinh doanh cho WebForms trừ khi một dự án đã sử dụng nó.

Tôi đã gửi email cho Scott Guthrie , một chuyên gia MVC tại Microsoft. Và có lẽ người đàn ông có trình độ nhất để trả lời câu hỏi này. Anh ấy tốt bụng trả lời:

"Các khách hàng khác nhau tìm kiếm các cách tiếp cận lập trình khác nhau, và rất yêu thích WebForms và nghĩ rằng nó thật tuyệt. Những người khác yêu thích MVC và nghĩ rằng nó thật tuyệt. Đó là lý do tại sao chúng tôi đang đầu tư vào cả hai."

Vì vậy, với tôi điều này nói rằng nó không phải là một vấn đề kỹ thuật. Đó là một "vấn đề mềm", nếu bạn muốn. Một trong những sở thích cá nhân. Đây là phù hợp với những gì một số bạn đã nói.

Cảm ơn tất cả các câu trả lời.

Đây là một câu hỏi cũ với rất nhiều câu trả lời nhưng không có câu trả lời nào tôi mong đợi được liệt kê.

Câu trả lời ngắn gọn là:

• Sử dụng ASP.NET MVC nếu bạn có ý định xây dựng một ứng dụng web đúng cách với các quy ước lập trình hiện đại và các mẫu được áp dụng cho nền tảng ASP.NET. Về phía bên dưới, bạn sẽ được biết cách HTML và tài nguyên phía máy khách (Javascript, CSS) hoạt động cũng như tăng cường tư duy lập trình MVC có đường cong học tập dốc nhưng đạt đến kết thúc bất ngờ một khi đã nắm bắt được.
• Sử dụng Biểu mẫu web ASP.NET nếu bạn đang sử dụng hoặc muốn sử dụng GUI-tập trung, RAD (Phát triển ứng dụng nhanh) , cách tiếp cận kéo và thả để tạo mẫu một cái gì đó rất nhanh, ví dụ như hành vi nút nhấn / lưới dữ liệu được nối trong 15 phút và giải pháp không nhằm mục đích trở thành thứ được các nhà phát triển hỗ trợ. Hoặc, Sử dụng ASP.NET Web Forms nếu bạn có nền tảng về phát triển GUI hoặc Windows Forms và bạn muốn chuyển kiến ​​thức của mình sang Web.

Nhưng để xem xét điều này đúng, bạn phải hiểu lịch sử của từng.

ASP.NET Web Forms là câu trả lời của Microsoft cho những người đã và đang xây dựng các ứng dụng web động bằng cách sử dụng các điều khiển ActiveX Visual Basic 6, DLL VB6 trên máy chủ và ASP Classic. Vào thời điểm đó, phát triển web bằng các công cụ Microsoft này là một mớ hỗn độn thực sự. Cùng với toàn bộ .NET Framework, sản phẩm của Microsoft về cơ bản sẽ quay trở lại bảng vẽ về cách thực hiện lập trình kinh doanh hiệu quả trên ngăn xếp Windows, ASP.NET Web Forms, thật tuyệt vời và tuyệt vời.

Toàn bộ cách tiếp cận là cung cấp cho các nhà phát triển những điều tốt nhất của cả hai thế giới tương tự như phát triển ứng dụng Windows, nhưng với sức mạnh của các dịch vụ internet. Ý tưởng là, giống như với "Biểu mẫu" VB6 / WinForms (một cửa sổ), một trang web cũng là một hình thức (giống như một cửa sổ, xem) và trên biểu mẫu đó bạn có thể kéo và thả nhãn, hộp văn bản, lưới dữ liệu, nút và các thứ khác mà các nhà phát triển GUI VB / WinForms đã quen thuộc.

Để tạo một nút làm một cái gì đó, sau khi kéo và thả nó, bạn chỉ cần nhấp đúp vào nút đó trong trình thiết kế và bùng nổ trong trình chỉnh sửa mã, cho biết biểu mẫu phải làm gì khi sự kiện "nhấp chuột" đó xảy ra. Đây chính xác là cách các nhà phát triển GUI Windows tạo ra phần mềm bằng cách sử dụng công cụ GUI của VB6 và các công cụ cạnh tranh, ngoại trừ bây giờ mã đang thực thi trên máy chủ! Ồ

Đây là công nghệ năm 2002. Thật tuyệt vời và đẹp đẽ khi là câu trả lời cho các giải pháp GUI hỗ trợ internet để phát triển RAD , nó mang lại cảm giác mạnh mẽ cho một thế giới lộn xộn của các nhà phát triển phần mềm có mục tiêu kinh doanh mà họ cần phải hoàn thành.

Thật không may, mô hình lập trình này nhấn mạnh rất nhiều phép ẩn dụ của lập trình Windows GUI mà nó mang theo gánh nặng của các chi tiết triển khai cần thiết, tất cả các hành lý vướng mắc cần thiết để phù hợp với vòng đời sự kiện và loại bỏ các chi tiết xấu xí của HTML đơn giản và tập lệnh mà các thành phần và điều khiển kéo và thả này sẽ xuất ra. Và vào cuối ngày, các nhà phát triển hỗ trợ các ứng dụng thực sự chắc chắn phải đào sâu vào các thành phần này hoặc tự viết, và do đó, họ sẽ chiến đấu với các cơ sở hạ tầng này, các trận chiến sẽ bỏ lại sau đống cọc, kéo tóc và những giọt nước mắt.

Sao lưu. Rửa tay. Hãy xem xét lại vấn đề kinh doanh. Mục tiêu kinh doanh của chúng tôi là gì?

Chúng ta cần xây dựng và quản lý các ứng dụng web . Hạn chế của chúng tôi là chúng tôi có World Wide Web, nằm trên HTTP, HTML, Javascript và CSS và trên máy chủ, chúng tôi có các quy tắc kinh doanh, cơ sở dữ liệu và một số ít ngôn ngữ lập trình tuyệt vời (ví dụ: C #). Chúng ta có thực sự cần ẩn dụ GUI Windows này để thúc đẩy phương pháp phát triển của chúng ta không? Tại sao chúng ta không thể chỉ tập trung vào các vấn đề của ứng dụng và loại bỏ các ẩn dụ GUI?

Đây là nơi ASP.NET MVC xuất hiện. Nó bắt đầu bởi một nhóm các nhà phát triển tự gọi mình là "Alt.Net", những người muốn quay lại các nguyên tắc phát triển phần mềm thuần túy và phù hợp. Không còn ồn ào, chỉ tập trung vào các mục tiêu kinh doanh và thực tiễn tốt nhất về phần mềm.

Điều này thực sự dịch trong trường hợp này là:

1. Tách biệt mối quan tâm . Ví dụ, một thành phần dữ liệu không cần biết dữ liệu của nó sẽ được hiển thị như thế nào, cũng không nên xem đánh dấu được đóng gói với các chi tiết cấu hình kết nối cơ sở dữ liệu và theo cách này, nhà phát triển có thể tập trung vào khu vực quan tâm của mình khi chỉnh sửa và mã kiểm tra.
2. Phơi bày và hỗ trợ đầy đủ cho việc tiếp xúc với sự hài hước của HTML và các tài nguyên liên quan . Trong Biểu mẫu web, HTML được giấu kín, các nhà phát triển không khuyến khích làm phiền với điều đó. Trong ASP.NET MVC, các nhà phát triển được khuyến khích quản lý các chi tiết đó; thực tế nó là một điều cần thiết Ưu điểm ở đây là nhà phát triển có thể học lại để đánh giá cao ngữ nghĩa rõ ràng của HTML, CSS và tập lệnh và làm việc với nó thay vì chống lại nó.
3. Khả năng kiểm tra đối tượng kinh doanh . Bộ điều khiển và mô hình phù hợp hơn nhiều cho thử nghiệm đơn vị lập trình, do đó việc triển khai có thể được xác nhận để đáp ứng các mục tiêu kinh doanh và các thay đổi có thể được xác minh rằng chúng sẽ không bị hỏng. Với Web Forms, rất khó để kiểm tra vì các thành phần không được thiết kế để được kiểm tra riêng lẻ và toàn bộ đầu ra phát triển xoay quanh các mẫu trang và vòng đời sự kiện của chúng với mớ logic kinh doanh và logic trình bày đan xen sâu sắc.

Lưu ý rằng HTML đã là ngôn ngữ đánh dấu cấp cao, cũng như Javascript là ngôn ngữ lập trình cấp cao. Toàn bộ câu chuyện sẽ khác nếu chúng ta làm việc với ngôn ngữ hội và C.

Sau đó, mở rộng # 2, một mục tiêu khác của ASP.NET MVC là cho phép các nhà phát triển tổ chức các chi tiết mặt trước của phần 'xem' các giải pháp của họ và tận dụng nền tảng phong phú mà phần còn lại của ngành đã xây dựng nền tảng máy khách phía trước.

Bạn sẽ thấy rằng các nhà phát triển ASP.NET MVC cảm thấy như ở nhà khi sử dụng các thư viện Javascript phong phú và các kỹ thuật tạo khuôn mẫu phía máy khách mà không phải chiến đấu với kiến ​​trúc phía máy chủ. Đây không phải là trường hợp ban đầu với ASP.NET Web Forms, vì Web Forms không muốn bạn xem xét HTML hoặc script, ngoại trừ nếu bạn thực sự phải , trong trường hợp đó, hãy cẩn thận, nó không dành cho người mờ nhạt của trái tim.

Tôi hoàn toàn chuyển đổi hoàn toàn sang ASP.NET MVC và chưa nhìn lại, điều đó nói rằng tôi vẫn phải duy trì một số ứng dụng WebForms rất lớn. Đây là của tôi về nó:

WebForms
Sử dụng những thứ này khi bạn có một số việc nặng nề nghiêm trọng phải làm với lưới điện. Các điều khiển lưới thực sự rất đẹp khi bạn có một bộ dữ liệu đơn giản phù hợp với định dạng bảng và bạn muốn cung cấp một cách đơn giản để người dùng cập nhật hồ sơ. Vâng, tôi biết rằng MVC 4 có một loại danh sách Ajax thực sự hấp dẫn mà bạn có thể sử dụng, nó hoạt động rất tốt, nhưng trong kinh doanh của chúng tôi, chúng tôi thường cần phải có một cái gì đó chạy ngày hôm qua và lưới điện cũ hoạt động tốt và người dùng rất vui khi được có thể tab trên một lưới với glee. Đối với tôi đó thực sự là điều tốt nhất về WebForms đối với tôi; nhưng, như Ryanchỉ ra WebForms có thể là một mớ hỗn độn thời gian lớn bởi vì bạn đang chơi cả hai phía của hàng rào từ một tệp mã phía sau tiện lợi. Nó có thể là cả một bông hồng và một cái gai cùng một lúc để giữ cho tất cả các công cụ loại điều khiển của bạn được trộn lẫn với (các) chế độ xem của bạn.

MVC
Sử dụng điều này khi bạn thực sự muốn tự lăn và bạn có cơ hội bắt đầu một ứng dụng từ đầu. Có một ứng dụng MVC được xác định rõ ràng là một công việc nhiều hơn để bắt đầu nhưng lợi ích của nó trong khả năng bảo trì vượt xa chi phí thiết lập ban đầu. Nếu bạn muốn thực hiện các tương tác Ajax thú vị, thích viết mô hình của bạn bằng mã, như các url và tuyến sạch, và có thể kiểm soát toàn bộ dòng ứng dụng của bạn thì đây chắc chắn là cách tốt nhất. Ban đầu nó cần một số quen thuộc nhưng tôi nghĩ đó là lựa chọn tốt hơn cho các ứng dụng của Greenfield.

Để kết luận, đối với tôi, nó đi xuống lưới và! Lưới. :)

Kinh nghiệm của tôi:

• Đã viết dự án CakePHP trong một năm.
• Hoàn thành một dự án Webforms cỡ trung bình trong sáu tháng.
• Làm việc trên một dự án Windows Forms trong ba năm.

Sau trải nghiệm đó, tôi đã thử viết một ứng dụng khác bằng cách sử dụng các biểu mẫu web và cảm thấy thất vọng sau khi phải vật lộn khoảng một ngày với cách các biểu mẫu web cố gắng bảo vệ nhà phát triển khỏi thực tế rằng họ đang phát triển một ứng dụng sử dụng html, javascript và css.

Sau đó, tôi đã thử dùng MVC và có thêm quyền kiểm soát trực tiếp đầu ra (và một số kinh nghiệm với mô hình MVC từ CakePHP) Tôi đã có thể hoàn thành ứng dụng đơn giản đó chính xác theo cách tôi muốn trong khoảng 1/2 mỗi ngày.

Tính khả dụng của các khung UI mạnh mẽ như jQuery giúp loại bỏ rất nhiều sự hấp dẫn của việc từ bỏ quyền kiểm soát trực tiếp đầu ra để sử dụng các thành phần UI được xây dựng sẵn cồng kềnh.

Tôi thích các biểu mẫu web vì nền tảng của tôi là phát triển windows.

Tốc độ phát triển là một vấn đề quan trọng và tôi có thể dễ dàng chuyển một vấn đề cho ai đó ở Ấn Độ để khắc phục qua đêm với các biểu mẫu, ngoài ra, nếu tôi gặp vấn đề về tốc độ trên một trang, một cuốn sách thực sự hay về tốc độ asp.net rất tiện dụng (Rick Kiessig là người đàn ông).

webforms dành cho ex windows mọi người mvc dành cho người web

nhưng, trong thế giới hiện đại, nơi Rick đã viết một cuốn sách tuyệt vời, với các máy chủ tăng tốc độ hàng ngày và các lập trình viên giá rẻ ở Ấn Độ, tốt, các biểu mẫu web có lợi thế

2 xu của tôi là luôn sử dụng ASP.NET MVC cho các dự án mới nếu bạn có tùy chọn. Theo tôi, các biểu mẫu web không phải là một cách tốt để phát triển các ứng dụng web, thời kỳ.

Tôi nghĩ rằng trừu tượng hóa REST cơ bản là xấu, toàn bộ mô hình postback là xấu, cách html / css được trao với sự phụ thuộc vào trình soạn thảo GUI là xấu, sự nhấn mạnh vào các công cụ như trình hướng dẫn và GUI để thiết lập nội dung là xấu, các URL là xấu.

Tôi đã đọc tất cả các câu trả lời và cảm thấy kinh nghiệm cá nhân của tôi sẽ thêm một cái gì đó vào các câu trả lời ở trên.

3-4 năm trở lại đây, tôi đã phát triển 2-3 dự án trang web bằng cách sử dụng Webforms. Trong khoảng thời gian đó, MVC không xuất hiện hoặc tôi không nghe nói về nó. Sự phát triển là tự nhiên (tôi đến từ phát triển Win-Forms không có kinh nghiệm phát triển web trước đó) vì tôi không cần phải học HTML chi tiết và điều khiển web đã giúp ích rất nhiều (rất nhiều, nó giúp cuộc sống dễ dàng hơn) .

Bây giờ, sau tất cả thời gian đó, tôi đã không làm việc với bất kỳ dự án web nào cho đến gần đây và chỉ xây dựng một số ứng dụng Windows bằng WPF.

Vài ngày trước, tôi có một ý tưởng cho một trang web và nghĩ đến việc phát triển nó: lần này là về MVC (vì nó được nói đến ở khắp mọi nơi, ngoài việc tôi cần phải tìm hiểu, vì vậy tôi chọn MVC). Dự án vẫn đang trong giai đoạn phát triển, vì tôi vẫn đang học hỏi và xây dựng cùng nhau.

Vì vậy, sự khác biệt chính tôi tìm thấy b / w hai là sau: -

• Đối với ai đó đến từ sự phát triển của windows, các hình thức Web sẽ luôn thuận lợi. Đường cong học tập Asp.net cho một nhà phát triển windows hơi dốc

• Đối với ai đó đến từ phát triển web trong một số công nghệ khác, MVC sẽ được ưa chuộng vì nó chế giễu tất cả những thứ mới nhất.

• Phát triển dễ dàng và gọn gàng hơn trong MVC nếu bạn được trang bị kiến ​​thức tốt về HTML và CSS

• Triển khai vẫn là một vấn đề. Trong các hình thức web, người ta chỉ cần sao chép và dán. Nhưng, điều này đòi hỏi một số điều phải được thực hiện.

Nói tóm lại, cả hai sẽ ở lại đây một lúc.

Tôi chưa thấy sự cân nhắc này được đưa ra trong số 15 câu trả lời hiện có cho chủ đề này, nhưng tôi nghĩ rằng nó đáng để xem xét.

Theo kinh nghiệm của tôi, Web Forms giống với Win Forms và WPF hơn là MVC. Vì điều này, tôi nghĩ người ta có thể cân nhắc lựa chọn Biểu mẫu web khi nhóm có nhiều kinh nghiệm nhất về loại công nghệ đó hoặc khi dự án Biểu mẫu web sẽ cung cấp giao diện cho cùng một bộ dữ liệu như Win Forms hiện có (hoặc được phát triển đồng thời) Dự án WPF. Làm như vậy cho phép các nhà phát triển giao thoa giữa các dự án dễ dàng hơn, vì logic ứng dụng có thể khá giống nhau giữa hai dự án.

Như các câu trả lời khác đã chỉ ra, phát triển trên khung MVC tương tự như phát triển web trong Ruby, PHP, Python, v.v. so với các đối tác Microsoft của nó; do đó, tự nhiên sự lựa chọn của MVC có thể bị ảnh hưởng bởi kinh nghiệm của các nhóm trong các lĩnh vực đó, cùng với các yếu tố được gửi trong các câu trả lời khác.

Lý do chúng tôi không đến MVC vài năm trước là vì nó là một công nghệ chưa trưởng thành của Microsoft. Trong vài năm qua, chúng tôi hiện đang ở phiên bản trưởng thành hơn (4) và MS dường như đã tìm ra nơi họ sẽ thực hiện với điều này. Tuy nhiên, chúng tôi vẫn miễn cưỡng phát triển các ứng dụng LOB chính bằng cách sử dụng MVC vì các tính năng chúng tôi muốn sử dụng trong phiên bản 4 yêu cầu máy chủ windows 2012 (lại là ổ cắm web qua IIS8). Tôi nghĩ rằng sau 1 năm nữa chúng tôi sẽ chấp nhận MVC hơn vì hy vọng sẽ có nhiều kiểm soát của bên thứ ba hơn, công nghệ sẽ ổn định và chúng tôi sẽ có cơ sở hạ tầng để hỗ trợ nó.

Quyết định này phụ thuộc vào sở thích của bạn, vào các yêu cầu của bạn hoặc thậm chí vào kiến ​​thức và kinh nghiệm của bạn.

Thời gian đào tạo học MVC hoặc thời gian để giao hàng. Tất cả những điều này quan trọng để chọn một hoặc aproach khác.

Không phải cái đó tốt hơn cái kia, đơn giản là cả aproach hay framework đều có ưu và nhược điểm.

Cá nhân tôi thích MVC 3, tôi khuyên bạn nên thử trải nghiệm của riêng bạn, nhưng tôi cần nói rằng chương trình trong MVC là một cách sạch sẽ, vui vẻ, linh hoạt, có thể mở rộng, an toàn và có cấu trúc.

Trân trọng,

Lý do duy nhất khiến tôi chọn WebForms thay vì MVC là vì bạn có nhiều điều khiển UI bên thứ 3 cho WebForms hơn MVC. Tôi chọn MVC vì tôi đã làm việc quá nhiều với WebForms và tôi muốn làm việc với một cái gì đó mới / mới, nhưng vẫn từ MS shop :)

Về cơ bản, không có gì ngăn bạn tắt viewstate trong WebForms và sử dụng ViewModels và if / cho các vòng lặp thay vì ràng buộc mô hình và các điều khiển phía máy chủ.

Đây là mã WebForms hay MVC:

<% foreach (var item in Model.Items) { %>
<p><%: item.Name %></p>
<% } %>

Hạn chế duy nhất tôi tìm thấy trong WebForms là nếu bạn sử dụng Dependency Injection / Inversion of Control, bạn không thể tiêm chích hàm vì các trang WebForms phải có hàm tạo không tham số, do đó bạn phải sử dụng phép tiêm thuộc tính. Đây thực sự là một vấn đề lớn như vậy?

ASP.NET MVC thực sự là một câu trả lời cho Ruby, và cách thức mới, hợp thời trang và (IMO) tốt hơn để tách trình duyệt (máy khách) khỏi máy chủ càng nhiều càng tốt.

ASP.NET Webforms cung cấp cho bạn nhiều quyền kiểm soát máy khách từ phía máy chủ, với quyền truy cập trực tiếp vào khá nhiều thứ. Về cơ bản, khung nhìn và bộ điều khiển của bạn là một trong cùng, nó cung cấp cho bạn rất nhiều sức mạnh và hầu hết rất nhiều lần lộn xộn.

ASP.NET MVC tách biệt chế độ xem và bộ điều khiển bằng cách tách rời khớp nối chặt chẽ của tệp .aspx và tệp .aspx.cs đi kèm với chúng trong các biểu mẫu web.

Về cơ bản, sự khác biệt là có quá trình xử lý của bạn nhiều hơn (thường là tất cả) để hiển thị dữ liệu vào tệp xem và để lại logic nghiệp vụ và phần còn lại trong bộ điều khiển, giữ cho chúng sạch hơn theo quy ước, nhưng cũng ít truy cập hơn vào mỗi khác với biểu mẫu web cho phép.

Theo tôi, chúng có liên quan đủ và có những khả năng gần giống nhau mà nó nên được ưu tiên.

Một nhà phát triển WebForms tuyệt vời có thể tạo ra một sản phẩm mạnh mẽ không kém gì một nhà phát triển MVC tuyệt vời. Nhưng nhà phát triển WebForms tuyệt vời đang cố gắng ép buộc bản thân chấp nhận MVC sẽ sớm xuất hiện. Điều tương tự cũng xảy ra với một nhà phát triển MVC tuyệt vời khi cho WebForms.

Chúng không phải là các thực thể hoàn toàn riêng biệt và miễn là Microsoft tiếp tục hỗ trợ cả hai, tôi tin rằng bạn sẽ tiếp tục thấy một nhóm các nhà phát triển đặc biệt cho mỗi nhóm.

Đây là tất cả về sự lựa chọn cá nhân, giả sử tất cả chúng ta đều thành thạo với công nghệ chúng ta sử dụng. Tôi đã sử dụng phương pháp thiết kế WebForms trong nhiều năm và tôi phải nói rằng nhược điểm duy nhất là do cách tiếp cận đơn giản, nhiều người không dành thời gian để khai quật khả năng to lớn của nó.

Gần đây tôi đã sử dụng MVC để hoàn thành một dự án và trong khi tôi khá thích cách tiếp cận thiết kế để phát triển ứng dụng (giúp bạn kiểm soát nhiều hơn, các url sạch, SOC, v.v.), thì thực sự không có gì nhiều, mà WebForms không thể cung cấp. Trong thực tế, sự xuất hiện của jQuery và nó hoạt động với WebForms (cũng như MVC) đã làm cho các đối số này ít gặp vấn đề hơn. Và khi mọi người nói về việc phân tách mối quan tâm như một lợi thế mà MVC có trên MVP, tôi hỏi họ biết họ biết bao nhiêu về lập trình Hướng đối tượng và họ đưa vào sử dụng nguyên tắc trừu tượng và đa hình như thế nào.

Tôi hiện đang thoải mái sử dụng cả hai công nghệ và tôi chọn và chọn dựa trên tình huống. Thẳng thắn mà nói, điều đó tùy thuộc vào bạn, nhưng sự thật vẫn là không phải ai cũng dành thời gian để tìm hiểu sâu về những gì một công nghệ cụ thể có khả năng.

Khi gặp vấn đề về lập trình, tôi thường tìm đến web để tìm câu trả lời. Webforms có hàng tấn thông tin / thành phần để làm bất cứ điều gì. Trong MVC do có ít nguồn trực tuyến hơn và các lớp trừu tượng cần thiết để làm cho một cái gì đó hoạt động đã đặt ra một giới hạn trong những điều mà tôi có thể làm một lần. Tổng số MVC giết chết năng suất của tôi với tư cách là nhà phát triển trong khi với Webforms thì không. Vì vậy, bây giờ tôi đang gắn bó với các biểu mẫu web cho đến khi MVC đủ trưởng thành để thay thế nó.

Chà, WebForms có sẵn nhiều tài nguyên học tập hơn (đơn giản là do nó cũ hơn) và do đó, các lập trình viên mới không "biết" sẽ có nhiều khả năng tìm thấy thông tin liên quan đến công nghệ cũ này hơn là các công cụ mới hơn như MVC .

Các lập trình viên cao cấp / có kinh nghiệm đã lớn tuổi và sẽ thành thạo công nghệ cũ hơn do thực tế là họ đã lập trình trong đó lâu hơn so với những người mới hơn.

Trừ khi bạn có thể chi tiền và công sức để giúp các bạn thành thạo MVC như họ đang ở trong các ứng dụng WebForms, chắc chắn bạn sẽ cố gắng và nâng cấp lên nền tảng mới càng lâu càng tốt.

Vì vậy, nó trình bày một số vấn đề hậu cần: Lợi ích của MVC có cao hơn chi phí về chất lượng kém hơn và thời gian triển khai không? Nếu tôi có một trang web được viết hoàn toàn bằng WebForms, nó có đáng để bỏ công sức và tiền bạc để tích hợp MVC vào nó không?

Như đã nêu bởi một người bình luận trước đó, MVC cũng ngăn bạn đạt được mức giao diện tương tự với bộ điều khiển như bạn có thể làm với WebForms. Mặc dù tôi hoàn toàn dành cho khía cạnh "Giữ cho người dùng không phải nhồi nhét / học hỏi" mọi thứ, nhưng vẫn có thể gây rắc rối một cách vô lý cho các đội khi triển khai / thực hiện một chương trình một cách điên cuồng theo mô hình đó cho mọi thứ họ viết.

Tôi nghĩ khoảng cách giữa hai công nghệ này không rộng như trước đây.

• Các biểu mẫu web có thể sử dụng công cụ định tuyến mà MVC sử dụng (hoặc một cái gì đó rất giống nhau).
• Trình quản lý tập lệnh có thể kết hợp các tập lệnh, tải từ CDN và thậm chí trì hoãn việc tải tập lệnh.

Để trả lời trực tiếp câu hỏi của bạn, tôi nghĩ rằng nó tùy thuộc vào sở thích và / hoặc dự án là gì. Cả hai đều có một cách tiếp cận khác nhau đáng kể để phát triển. Cá nhân tôi đã làm việc để chuyển sang MVC, nhưng vẫn thích làm việc với Webforms. Tôi nghĩ rằng câu trả lời cho thời tiết bạn nên sử dụng MVC hoặc Webforms là để bạn quyết định thông qua việc trải nghiệm cả hai công nghệ.