JavaScript giao diện thuần túy với API Web so với chế độ xem MVC với ajax


14

Đây là một cuộc thảo luận cho những suy nghĩ của mọi người ngày nay về cách phân chia một ứng dụng web.

Tôi đã quen với việc tạo một ứng dụng MVC với tất cả các khung nhìn và bộ điều khiển của nó. Tôi thường sẽ tạo một chế độ xem đầy đủ và chuyển lại cho trình duyệt theo yêu cầu toàn trang, trừ khi có các khu vực cụ thể mà tôi không muốn cư trú ngay và sau đó sẽ sử dụng các sự kiện tải trang DOM để gọi máy chủ tải các khu vực khác sử dụng AJAX.

Ngoài ra, khi nói đến việc làm mới một phần trang, tôi sẽ gọi một phương thức hành động MVC sẽ trả về đoạn HTML mà sau đó tôi có thể sử dụng để điền vào các phần của trang. Điều này sẽ dành cho các khu vực mà tôi không muốn làm chậm tải trang ban đầu hoặc các khu vực phù hợp hơn với các cuộc gọi AJAX. Một ví dụ sẽ là cho phân trang bảng. Nếu bạn muốn chuyển sang trang tiếp theo, tôi sẽ thích nó hơn nếu một cuộc gọi AJAX có thông tin đó thay vì sử dụng làm mới toàn bộ trang. Nhưng cuộc gọi AJAX vẫn trả về một đoạn HTML.

Câu hỏi của tôi là. Có phải suy nghĩ của tôi về cổ xưa này bởi vì tôi đến từ một nền .net chứ không phải là một nền tảng mặt trước thuần túy?

Một nhà phát triển giao diện người dùng thông minh mà tôi làm việc cùng, thích làm ít nhiều không có gì trong các chế độ xem MVC và muốn làm mọi thứ ở giao diện người dùng. Ngay xuống các lệnh gọi API web điền vào trang. Vì vậy, thay vì gọi một phương thức hành động MVC, trả về HTML, anh ta muốn trả về một đối tượng tiêu chuẩn và sử dụng javascript để tạo tất cả các thành phần của trang.

Cách nhà phát triển giao diện người dùng có nghĩa là mọi lợi ích mà tôi thường nhận được khi xác thực mô hình MVC, bao gồm xác thực phía máy khách, sẽ không còn nữa. Điều đó cũng có nghĩa là bất kỳ lợi ích nào tôi nhận được khi tạo các chế độ xem, với các mẫu html được gõ mạnh, v.v. sẽ không còn nữa.

Tôi tin rằng điều này có nghĩa là tôi sẽ cần phải viết xác nhận tương tự cho xác nhận mặt trước và mặt sau. Javascript cũng cần phải có nhiều phương thức để tạo tất cả các phần khác nhau của DOM. Ví dụ, khi thêm một hàng mới vào một bảng, tôi thường sử dụng chế độ xem một phần MVC để tạo hàng và sau đó trả lại hàng này như một phần của lệnh gọi AJAX, sau đó được đưa vào bảng. Bằng cách sử dụng cách kết thúc giao diện thuần túy, javascript sẽ lấy một đối tượng (ví dụ: một sản phẩm) cho hàng từ lệnh gọi api và sau đó tạo một hàng từ đối tượng đó. Tạo từng phần riêng lẻ của hàng của bảng.

Trang web được đề cập sẽ có rất nhiều lĩnh vực khác nhau, từ quản trị, biểu mẫu, tìm kiếm sản phẩm, v.v ... Một trang web mà tôi không nghĩ cần phải được kiến ​​trúc theo một cách ứng dụng một trang.

Suy nghĩ của mọi người về điều này là gì?

Tôi quan tâm để nghe từ dev dev front end và back end devs.


Thảo luận tương tự về SO về việc tách API và máy khách stackoverflow.com/questions/10941249/ triệt
Don Cheadle

Câu trả lời:


10

Tôi cũng hơi nghi ngờ rằng mọi ứng dụng web mới cần phải là một SPA nhưng có một điều tôi được bán 100% với tư cách là một nhà tổng quát với phần lớn kinh nghiệm của mình về phía khách hàng là kiến ​​trúc hướng dịch vụ hoàn toàn thô thay vì dữ liệu HTML cho khách hàng là cách để bạn tải các trang / lượt xem được dựng sẵn từ máy chủ và thực hiện nhiều nội dung động với dữ liệu sau khi tải trang hoặc xây dựng gần như mọi thứ 100% bằng JavaScript.

Những lý do này thích hợp hơn cho nhà phát triển phía máy khách cũng giống như lý do không ai muốn HTML trong cơ sở dữ liệu. Nhà phát triển phía khách hàng phải làm gì khi họ muốn sử dụng một bảng chẳng hạn khi họ được trao HTML? Chi phí hiệu năng xử lý tất cả những gì trên máy khách là không đáng kể so với việc thực hiện một yêu cầu máy chủ khác để làm điều đó cho bạn. Ngoài ra, việc xây dựng HTML được bao phủ khá tốt trong vùng đất JS. Sắp xếp dữ liệu và xây dựng các hàng bảng HTML mới từ đó là một công việc khá nhỏ đối với một nhà phát triển phía khách hàng có kinh nghiệm.

Và công dụng của kiến ​​trúc mặt sau là mặt trước cho một thiết bị khác có thể cần phải làm một cái gì đó kỳ lạ như các widget thực hiện 100% canvas hoặc cấu trúc HTML hoàn toàn khác nhau? Tại sao một nhà phát triển phía khách hàng phải tải lên phòng thu trực quan hoặc gõ cửa nhà phát triển phía sau để thực hiện một chỉnh sửa trình bày nghiêm ngặt?

Đối với những lo ngại của bạn về việc mất xác thực mẫu được gõ mạnh, hãy tin tôi khi tôi nói rằng nếu bạn đang làm việc với nhà phát triển phía khách hàng có thẩm quyền, bạn sẽ không tìm thấy .NET framework hay công cụ phòng thu trực quan nào phù hợp hơn hậu môn kim cương với bụi bặm về HTML hợp lệ, được hình thành tốt hơn so với anh ấy.

Từ phối cảnh toàn ngăn xếp, tôi thích nó bởi vì điều đó có nghĩa là tôi sẽ không bao giờ phải câu cá vì lý do kinh doanh hay ứng dụng, một số yutz đã quyết định thả vào lớp tạo mẫu. Chưa kể tải trên mỗi người dùng sẽ tắt máy chủ của bạn trong khi trong nhiều trường hợp thực sự cải thiện trải nghiệm tải cho người dùng trong các trình duyệt hiện đại với máy tính hiện đại.

Tôi nghĩ việc lập luận về kiến ​​trúc mặt sau cũng dễ dàng hơn khi bạn tách biệt hoàn toàn với tất cả các công cụ trình bày. Bạn không còn lấy dữ liệu để trộn nó vào một số HTML. Bạn đang kết hợp nó lại với nhau để tạo ra một cấu trúc dữ liệu độc lập với việc thực hiện liên quan đến việc sử dụng chung hơn là những gì sẽ được thực hiện với nó ở phía bên kia. IMO, điều đó có xu hướng dẫn đến sự nhất quán hơn trong cách xử lý mọi thứ vì dữ liệu hiện là mục tiêu cuối cùng thay vì bước thứ hai của bước cuối cùng của quy trình và có ít cơ hội hơn cho các mối quan tâm không liên quan để vượt qua dây dẫn của họ.


điểm tốt về tách biệt mã HTML từ logic phía máy chủ. Tôi thực sự ghét khi tất cả các ngôn ngữ được trộn lẫn. Đôi khi bạn thấy mã có C #, SQL, HTML, JavaScript, RazorSharp hoặc PHP trong cùng một tệp chết tiệt. Cũng không bình luận tiếng Anh. Chắc chắn nó hoạt động và có lẽ nó đã khá nhanh để viết nó sau đó, nhưng là một vấn đề bảo trì sau một vài tuần.
ColacX

5

Tôi sẽ cung cấp giá trị 2 xu rất chủ quan của tôi (với giá trị của nó;)). Không có câu trả lời đúng hay sai cho vấn đề này và có nhiều cân nhắc trong thế giới thực ngoài các điểm của bạn, ví dụ:

  • Bạn có kinh nghiệm liên quan trong nhà? xây dựng một ứng dụng điều khiển phía máy khách rất khác với ứng dụng chủ yếu là máy chủ điều khiển với bộ kỹ năng hoàn toàn khác.
  • Bạn muốn nó mất bao lâu và bạn cần hỗ trợ trình duyệt nào? - bạn càng làm nhiều hơn trên máy khách, bạn sẽ càng gặp nhiều vấn đề về trình duyệt; IE8 gây đau đớn và hiệu suất JavaScript khá kém, nhưng có rất nhiều doanh nghiệp đang chạy các thiết lập XP / IE.
  • Những thiết bị nào mà người dùng của bạn sẽ xem trang web trên? Phân tích và chạy JavaScript có thể nhanh trên phiên bản Chrome gần đây - nhưng nó không có trên một thiết bị di động cũ, đặc biệt không phải là một lượng lớn JavaScript có tải logic kinh doanh trong đó
  • Làm thế nào quan trọng là tải ban đầu? Tạo khuôn mẫu máy chủ nhanh hơn khuôn mẫu của máy khách

Danh sách này không có nghĩa là toàn diện và nghe có vẻ như là một sự cố của khách hàng, đó không phải là ý định của tôi, tôi đã tạo ra các trang web với sự nhấn mạnh vào mặt trước.

Đối với tôi, nó thực sự phụ thuộc vào trải nghiệm người dùng và khả năng sử dụng lại API. Để giải quyết từng vấn đề này.

Nếu bạn định tạo một ứng dụng hoặc cung cấp API, sẽ có rất nhiều ý nghĩa trong việc sử dụng dự án API .Net, sau đó hình thành logic, kiểm tra và triển khai đa nền tảng. Trong kịch bản này, cách tiếp cận phía máy khách hoàn chỉnh có thể thuận lợi, API có thể được duy trì riêng và chỉ cung cấp giao diện cho ứng dụng của bạn. Bạn có thể sửa đổi logic và cấu trúc lại một cách thoải mái và chỉ cần giữ giao diện giống nhau. Bạn có thể dễ dàng viết các ứng dụng khác nhau cho các phương tiện khác nhau bằng cách sử dụng cùng một mã nền.

Lập luận mạnh mẽ nhất cho một giải pháp mặt trước thuần túy (theo ý kiến ​​của tôi) là về trải nghiệm người dùng.

Liệu (khi xem xét tất cả các nhược điểm), một ứng dụng trình duyệt JavaScript thuần có mang lại sự cải thiện đáng kể về khả năng sử dụng và trải nghiệm người dùng trên một trang web truyền thống không?

Khi tạo các trang web hoạt động như các ứng dụng gốc; Tôi cho rằng câu trả lời là có. Tuy nhiên, hầu hết các trang web không phải là phần mềm sạch này, do đó, vấn đề là đánh giá xem liệu quy trình làm việc của người dùng cá nhân có được hưởng lợi từ giao diện rất năng động hay không.

Tôi có một cái nhìn khá thực tế về điều này, nó không phải là một trong hai vấn đề; JavaScript rõ ràng sẽ chơi khá vui vẻ cùng với các công nghệ Máy chủ và bạn không phải chọn cái này hay cái kia - mỗi trang web không phải là một ứng dụng web duy nhất - nhưng không có gì ngăn bạn sử dụng Knockout, xương sống và những thứ tương tự trên các trang riêng lẻ cải thiện những thứ mà nó thấy cần thiết


Điểm thú vị.
nhãn cầu

3

Tôi có một mối quan hệ yêu-ghét với các ứng dụng nặng phía trước.

Một mặt, tôi thích viết JavaScript và tôi yêu trình duyệt như một môi trường thực thi.

Mặt khác, cả hai đều cảm thấy giống như một chiếc xe đua Công thức 1 có lỗ trên động cơ. Nó thực sự hiểu rõ điều này: Bạn có thể ngăn chặn sự trùng lặp logic kinh doanh giữa C # và JavaScript không? Nếu vậy, hãy sử dụng bất kỳ phương pháp nào để tạo chế độ xem mà bạn cho là xứng đáng. Nếu bạn đang sao chép logic nghiệp vụ bằng hai ngôn ngữ, bạn có thể có một nhà phát triển giao diện người dùng chỉ muốn viết JavaScript và không nhìn thấy bức tranh lớn.

Đối với sự khác biệt kỹ thuật:

Kết xuất một phần và cung cấp cho khách hàng:

  • Dễ dàng và nhanh chóng để thực hiện
  • Ngăn chặn logic kinh doanh phụ trợ khỏi bị trùng lặp ở mặt trước
  • Có thể dẫn đến tải trọng HTTP lớn hơn nhiều cho trình duyệt. Không phải là một điều xấu trên máy tính để bàn có kết nối băng thông cao. Rất tệ trên điện thoại di động yếu trong khi bạn đang ngồi trên tàu cao tốc giảm tốc độ theo dõi ở tốc độ 60mph và 1.000 điện thoại di động khác đồng thời ngắt kết nối với một tháp di động và cố gắng kết nối lại với tháp di động tiếp theo.

Cung cấp JSON và hiển thị một mẫu phía máy khách:

  • Có thể dẫn đến tải trọng HTTP nhỏ hơn HTML, điều này có thể khiến ứng dụng có vẻ phản hồi nhanh hơn các kết nối mạng không đáng tin cậy hoặc chậm
  • Nhiều ngôn ngữ tạo khuôn mẫu JavaScript có đầy đủ tính năng, có nghĩa là chúng tôi không cần phụ trợ chỉ để tạo một số HTML

Đôi khi tôi nghĩ rằng các khung JavaScript mới hơn đang ném em bé ra ngoài bằng nước tắm --- người đàn ông tôi hy vọng tôi sẽ không trở thành một lập trình viên khó tính ...


1
Sự trùng lặp của BẤT K sort loại logic nào cũng là một vấn đề tôi đã suy nghĩ. Nhưng một số điểm thú vị.
nhãn cầu

0

Trong ứng dụng cuối cùng của tôi, tôi đã kết hợp REST api và JavaScript front-end.

Những gì tôi đã làm là:

  • Tôi đã tạo một API REST cho các hoạt động CRUD.
  • Tôi đã tạo một ứng dụng Javascript để tải các mẫu HTML được xác định trước và điền vào dữ liệu được trả về từ API REST.

Về cơ bản, giao diện người dùng JS giao tiếp với API REST cho các hoạt động CRUD và điền dữ liệu HTML với dữ liệu được trả về hoặc dữ liệu đã tạo hoặc xóa dữ liệu đã xóa hoặc cập nhật dữ liệu đã thay đổi.

Do đó, chúng tôi có HTML thuần túy, chúng tôi xử lý trên máy khách, chúng tôi sử dụng băng thông ít hơn bằng cách không phải tải tất cả HTML và có thể mang lại trải nghiệm Web 2.0 thực sự cho người dùng.

Tôi không thực hiện xác nhận kinh doanh ở mặt trước để đảm bảo an toàn và sao chép mã, vì bất kỳ ai cũng có thể thay đổi dữ liệu trước khi gửi chúng đến máy chủ và chúng tôi phải xác thực lại dữ liệu trên máy chủ. Do đó, điều này sẽ dễ dàng bị hack. Tất cả các xác nhận được thực hiện ở mặt sau. Xác nhận ở phía máy khách chỉ được thực hiện cho các loại đầu vào.

Ưu điểm:

  • Cơ sở để thực hiện các thay đổi trong HTML do thực tế nó không được tạo bởi JS;
  • Tiêu thụ băng thông thấp hơn bằng cách sử dụng ajax và JSON;
  • Tiêu thụ xử lý máy chủ thấp hơn, vì HTML được đặt ở phía máy khách;
  • Cải thiện trải nghiệm người dùng bằng cách sử dụng JS để thay đổi màn hình, cho phép sử dụng hiệu ứng và tăng tốc độ kết xuất.
  • Sử dụng tốt hơn giao thức HTTP, bằng cách sử dụng REST.

Nhược điểm:

  • 2 ứng dụng được duy trì;
  • Phụ thuộc vào xử lý máy khách, có thể xấu do phần cứng kém.

Hi vọng điêu nay co ich.

Trân trọng,


xử lý công việc trên quy mô khách hàng tốt hơn. máy chủ thường phải chạy rất nhiều ứng dụng khác cũng tiêu tốn tài nguyên máy chủ. Nếu máy chủ gặp sự cố thì ai cũng phải chịu.
ColacX

Tôi không hiểu quan điểm của bạn. Nhưng nếu máy chủ gặp sự cố, bất kể bạn chọn kiến ​​trúc nào, mọi người đều phải chịu đựng.
Bruno João

đó là lý do tại sao bạn nên làm cho máy chủ làm việc ít hơn. và có logic ít phức tạp hơn. do đó làm giảm sự căng thẳng trên các máy chủ. do đó giảm nguy cơ cho sự cố máy chủ. mặc dù chúng vẫn có thể xảy ra nhưng chúng sẽ xảy ra ít thường xuyên hơn thông thường khi bạn thực hiện cập nhật, bạn có nguy cơ giới thiệu các lỗi. làm ít cập nhật hơn trên các máy chủ. giữ càng nhiều công việc càng tốt trên máy khách.
ColacX

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.