angularjs và ASP.NET MVC: chiến lược tốt nhất cho các mô hình khách hàng

Question

Tôi hiện đang xem xét mô hình phía khách hàng ràng buộc với các mẫu HTML đặc biệt là với angularjs. Tôi đã tự hỏi chiến lược nào là tốt nhất để truy xuất chế độ xem khách hàng từ máy chủ, ví dụ: một viewmodel không chỉ bao gồm các dữ liệu để chỉnh sửa nhưng cũng là dữ liệu cho các danh sách chọn hoặc thả xuống danh sách vv ..

Như tôi đã nhìn thấy nó, người ta có một vài lựa chọn

1. lấy một viewmodel từ máy chủ sử dụng ví dụ api web, có chứa TẤT CẢ các dữ liệu cần thiết cho mô hình xem
2. làm cho mô hình chế độ xem phía máy khách thành javascript bên trong phía máy chủ html
3. truy xuất dữ liệu cho chế độ xem bằng cách sử dụng nhiều cuộc gọi api trên web, ví dụ: một dữ liệu chính cần chỉnh sửa và một cho mỗi dữ liệu bổ sung (chọn danh sách)

Tôi không gặp phải nhiều ví dụ cho tùy chọn 1 vì dường như api web được sử dụng chủ yếu cho hoạt động crud trả về dữ liệu cụ thể cho một loại đối tượng, ví dụ Người hoặc tự

phương án 2 phù hợp với thực tế của máy chủ mô hình xem mặt với asp.net MVC nhưng tôi chưa thấy nhiều ví dụ sử dụng kỹ thuật này kết hợp với angularjs tùy chọn

3 trông sạch nếu ta xem xét tách của mối quan tâm, nhưng có bất lợi của nhiều yêu cầu ajax nhỏ hơn.

Bạn có thể chia sẻ suy nghĩ và trải nghiệm của mình không?

Answer 1

Tôi đồng ý với st. không bao giờ và chắc chắn đã sử dụng tùy chọn # 3 và tôi nghĩ rằng việc kết hợp $ resource và Web API sẽ là một sự kết hợp RAD hoàn hảo. Tuy nhiên, tôi cũng đã làm việc trên màn hình rất phức tạp, nơi tôi đã muốn thời gian phản hồi phụ thứ hai vì vậy tôi đã sử dụng để tối ưu hóa toàn bộ cột 'phát triển' - tôi phát triển bằng SQL Server làm cơ sở dữ liệu phụ trợ của mình. hỗ trợ nguyên gốc cho XML để trả về XML có cấu trúc từ một thủ tục đã lưu trữ mà sau đó tôi nối tiếp thành một Mô hình Net. (POCO) mà sau đó tôi chuyển tới một trình tuần tự Json để chuyển sang trình duyệt. Tôi có thể có một số xử lý kinh doanh bổ sung để thực hiện chống lại POCO nhưng điều này vẫn dẫn đến một cấu trúc mã rất đơn giản để chuyển một cấu trúc dữ liệu khá phức tạp. Thông thường nó cũng rất nhanh vì tôi đã thực hiện một cuộc gọi đến cơ sở dữ liệu và theo dõi và tối ưu hóa một thủ tục lưu trữ rất đơn giản.

Answer 2

Cá nhân, tôi sử dụng tùy chọn # 3. Ứng dụng sẽ yêu cầu "chuẩn bị trình chỉnh sửa", chẳng hạn như danh sách thả xuống thả xuống và yêu cầu tìm nạp dữ liệu bạn muốn chỉnh sửa (hoặc, nếu bạn đang tạo đối tượng mới, bất kỳ giá trị ban đầu mặc định nào). Tôi nghĩ rằng điều này tách mối quan tâm tốt hơn so với tùy chọn # 1, trong đó liên kết với nhau dữ liệu "mô hình" và "hỗ trợ" dữ liệu.

Nhưng như bạn đã chỉ ra, điều này thực hiện các cuộc gọi bổ sung và nếu chúng quá nhiều, có thể làm chậm đáng kể trang. (hoặc tăng độ phức tạp, trên một hình thức lớn với nhiều lĩnh vực phụ thuộc, đặt hàng có thể trở nên quan trọng).

Điều tôi thường làm là máy chủ cung cấp api "kết hợp" (ví dụ: /editor/prepare-all) trong khi cũng cung cấp các mẩu nhỏ (ví dụ: /editor/prepare-dropdown-1, /editor/prepare-dropdown-2). Khi trình chỉnh sửa của bạn tải, bạn sử dụng trình soạn thảo kết hợp; nếu có sự phụ thuộc giữa các trường, bạn chỉ có thể yêu cầu dữ liệu cho các trường phụ thuộc (ví dụ: /editor/prepare-dropdown-2?dropdown1-value=123). Tôi tin rằng điều này có ít tác động đến độ phức tạp của máy chủ.