ASP.NET MVC 5 so với AngularJS / ASP.NET WebAPI [đã đóng]


86

Tôi hiện đang đánh giá mô hình lập trình để tạo Ứng dụng web trong tương lai trong công ty của mình. Vì vậy, tôi sẽ quyết định giữa ASP.NET MVC 5 (với Razor Views) và AngularJS với ASP.NET WebAPI. Ưu / nhược điểm của hai mô hình lập trình này là gì?


4
Chà ... nếu bạn định neo AngularJS vào ASP.NET ... thì bạn không thực sự so sánh nó một cách công bằng. Nó giống như bạn đang tìm cách loại bỏ Javascript ra khỏi Angular, và đó không phải là cách nó diễn ra. Angular được coi là khuôn khổ của bạn cho máy khách và hoạt động tốt nhất khi bạn sử dụng rất ít khuôn mẫu phía máy chủ: simple-talk.com/blogs/2013/10/16/… . Những thứ như xác thực và những thứ tương tự có ý nghĩa, nhưng hãy bỏ qua dao cạo và chỉ cần đi thẳng .NET và tạo một lớp API cho Angular với nó.
Brian Vanderbusch

3
Tôi nghĩ những gì bạn thực sự cần chỉ là AngularJS với ASP.NET WebAPI. Tôi nghĩ rằng nó có tốt nhất của cả hai thế giới. Tôi đã thử kết hợp MVC với AngularJS và nó không phải là trải nghiệm tốt khi tôi gặp sự cố, vì vậy tôi khuyên bạn không nên mắc vào cái bẫy đó. Một điều tôi bỏ lỡ với cách tiếp cận này là lượt xem dựa trên thiết bị mà MVC với công cụ Razor có thể cung cấp. Phải có một cách để vượt qua điều này, nhưng tôi vẫn chưa đủ kinh nghiệm.
Kiran

Làm việc với Angular chỉ trong vài tháng ngắn ngủi (mặc dù có vẻ như là mãi mãi), tôi sẽ không bao giờ quay lại Razor. Càng làm việc với Angular, bạn càng đánh giá cao nó - sự linh hoạt và sức mạnh, đôi khi nó giống như ma thuật. Tôi nên nói rằng API Web không hoạt động tốt với Angular, ít nhất là trên biểu mẫu POST, nhưng điều đó có thể giải quyết được. Đây không phải là một quá trình chuyển đổi dễ dàng đối với cú pháp của lập trình viên C #, vì javascript không phải là một ngôn ngữ được đánh máy mạnh. Nhưng khi bạn vượt qua rào cản này, bạn sẽ đánh giá cao Angular.
Florida G.

Dao cạo là một thứ kinh khủng ngay cả trong số các động cơ tạo mẫu. Bạn sẽ nhận thấy sự gia tăng đáng kể về năng suất khi sử dụng góc cạnh trên bất kỳ động cơ tạo khuôn nào (Jade, tay lái, dao cạo, v.v.). Sử dụng chương trình phụ trợ phân phát JSON (có thể là web-api, node-express hoặc PHP) và giao diện người dùng góc cạnh. Và chỉ cần lưu ý, loại trực tiếp gần như không tốt bằng góc cạnh .... Tất cả tốt nhất ...
Giridhar Karnik

1
@BrianVanderbusch Không thực sự chắc chắn bạn đang nói về điều gì. Phần phụ trợ không quan trọng chút nào. Nó có thể là bất cứ điều gì. Anh ấy nói rằng anh ấy sẽ sử dụng ASP.NET làm phần phụ trợ và góc cạnh làm giao diện người dùng phía máy khách. Angular vẫn cần thực hiện các cuộc gọi đến máy chủ để lấy dữ liệu. Điều này không liên quan gì đến việc không cho Angular một sự so sánh công bằng.
user441521

Câu trả lời:


103

2 xu của tôi. Cá nhân tôi thích các chế độ xem HTML thuần túy, giao diện người dùng hoàn toàn góc cạnh cùng với giao diện người dùng Web API / EF / SQL Server, về cơ bản không có Razor. Razor là một phần trừu tượng để giúp các lập trình viên kết xuất HTML, ngày nay mọi người đều đi đến kết luận rằng việc loại bỏ những phần trừu tượng này là một ý tưởng tốt hơn, do đó, sự phát triển của ASP.NET từ các biểu mẫu web, sang MVC, v.v. Không thực sự khó khăn đối với các nhà phát triển nắm rõ HTML và sử dụng giao diện người dùng góc cạnh, hơn nữa điều này làm cho công việc của các nhà thiết kế giao diện người dùng dễ dàng hơn, họ có HTML và JSON / Javascript thuần túy, họ không cần phải tìm hiểu về MVC, Razor, bộ điều khiển và hành động. Chúng tôi đã từng làm việc hoàn toàn trên MVC, trong dự án mới nhất của mình, chúng tôi đã chuyển sang giao diện người dùng Web API và giao diện người dùng góc cạnh và chúng tôi nhận thấy rằng năng suất của nhà thiết kế giao diện người dùng của chúng tôi đã được cải thiện đáng kể.


3
Và tôi muốn thêm vào đó, với góc bạn có thể cập nhật các mẫu của bạn tự động, mà rõ ràng, tuyệt vời
Willem D'Haeseleer

4
Đúng vậy, khi nói đến việc phát triển giao diện người dùng năng động và nhạy bén hơn so với chi phí phát triển, thực sự không có sự cạnh tranh.
Mohammad Sepahvand

@ user189756 làm cách nào để bạn phân phối các trang HTML cho máy khách khi sử dụng phương pháp Web API?
Yoav

@Yoav Đây là một câu trả lời cũ, nhưng vào thời điểm đó, nó là một máy chủ lưu trữ MVC với một bộ điều khiển duy nhất.
Mohammad Sepahvand

1
@Yoav Chính xác. Nhưng tôi sẽ nói thêm rằng câu trả lời khác cũng rất tuyệt vời, đặc biệt là tính đến những thứ như SEO.
Mohammad Sepahvand

53

Tôi tin rằng bạn không thể so sánh. AngularJS là một khuôn khổ Ứng dụng Trang đơn (SPA) trong khi ASP.Net MVC sử dụng mô hình tiêu chuẩn trong đó người ta điều hướng giữa các trang. Bạn có muốn xây một SPA hay không là do các yếu tố như

  • Bạn có muốn SEO. Mà hầu hết các khuôn khổ giàu JS này đều có hỗ trợ hạn chế.
  • Làm cách nào để bạn có thể cấu trúc ứng dụng của mình dưới dạng SPA hoặc nhiều SPA.
  • Từ một ngôn ngữ an toàn kiểu C # sang lập trình JavaScript là một thách thức.
  • Học AngularJS và sử dụng nó một cách hiệu quả.

Chúng tôi sử dụng chế độ xem dao cạo MVC 5 tiêu chuẩn để thiết lập các chế độ xem AngularJS ban đầu, do đó bạn thậm chí có thể kết hợp chúng với nhau nếu cần.

Xem câu trả lời này Bạn có thể sử dụng AngularJS với Parse.com không? để lấy thêm ngữ cảnh.


12
"... trong khi ASP.Net MVC sử dụng mô hình chuẩn trong đó người ta điều hướng giữa các trang." Điều này chỉ đơn giản là sai. Các ứng dụng MVC - sử dụng dao cạo - có thể được thiết kế như SPA rất dễ dàng.
Sam

7
AngularJS không giới hạn SPAs, bạn rất tốt có thể xây dựng một trang web đa trang với góc cùng với với liên kết sâu ....
Giridhar Karnik

3
AngularJS không phải là một SPA. Bạn có thể sử dụng nó như một SPA, nhưng điều đó không tự động hoặc không cần thiết. Phải thêm ng-route phụ thuộc định tuyến vào để có định tuyến. AngularJS thật đáng kinh ngạc và có thể là một SPA tuyệt vời, nhưng thật ngớ ngẩn khi nói AngularJS = SPA.
Tom Stickel

5
TypeScript là một lựa chọn tốt cho kiểu js an toàn.
Kyle JV

9
AngularJS được tạo ra bởi Google. Nếu nó thiếu trong SEO thì họ đang làm sai.
Xứng đáng
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.