angularjs i ASP.NET MVC: najlepsza strategia dla modeli klienckich

Question

Obecnie poszukuję modelu strony klienta wiążącego się z szablonami HTML, szczególnie z angularjs. Zastanawiam się, jaka jest najlepsza strategia do pobierania modeli viewup z serwera, np. ViewModel zawierający nie tylko dane do edycji, ale również dane dla wybranych list lub list rozwijanych itp ..

Jak ja to widzę, jeden ma kilka opcji

1. pobierające jeden ViewModel z serwera przy użyciu np Web API, zawierające wszystkie dane potrzebne do modelu widoku
2. renderowania po stronie klienta ViewModel do JavaScript wewnątrz HTML po stronie serwera
3. Pobieranie danych o viewmodel przy użyciu wielu internetowych wywołań API, np jeden na główne dane mają być edytowane , a po jednym dla każdego dodatkowego zbioru danych (listy wyboru):

Nie natknąłem się na wiele przykładów opcji 1, ponieważ wygląda na to, że api internetowe są używane głównie do operacji crud zwracających określone dane dla jednego typu obiektu, np. Osoba lub Zamówienie

opcja 2 jest zgodny z praktyką serwerowych widok z boku modeli z ASP.NET MVC, ale nie widzieliśmy wiele przykładów przy użyciu tej techniki w połączeniu z angularjs

opcji 3 wygląda czysty, jeśli weźmie się pod uwagę rozdzielenia obawy, ale ma wadę wielu mniejszych żądań ajax.

Czy możesz podzielić się swoimi przemyśleniami i doświadczeniami?

Answer 1

Zgodziłbym się z ul. nigdy nie użyłem opcji 3 i myślę, że połączenie $ resource i Web API byłoby idealną kombinacją RAD. Jednak pracowałem również nad bardzo złożonymi ekranami, w których potrzebowałem sekundowych czasów odpowiedzi, więc uciekłem się do optymalizacji całej kolumny "rozwoju" - rozwijam się przy użyciu SQL Server jako mojej bazy danych backendów, więc użyłem jej natywne wsparcie dla XML do zwrócenia strukturalnego XML z procedury przechowywanej, którą następnie przekształcaję w model .Net (POCO), który następnie przekazuję do serializatora Json do przeniesienia do przeglądarki. Mogę mieć dodatkowe przetwarzanie biznesowe, aby wykonać działanie przeciwko POCO, ale nadal prowadzi to do bardzo prostej struktury kodu do przesyłania dość złożonej struktury danych. Zwykle jest także bardzo szybki, ponieważ wykonałem jedno połączenie z bazą danych, a monitorowanie i optymalizacja jednej przechowywanej procedury jest bardzo prosta.

Answer 2

Osobiście korzystam z opcji # 3. Aplikacja wysyłałaby prośby o "przygotowanie edytora", na przykład zapełnianie list rozwijanych i żądania pobrania danych, które chcesz edytować (lub, jeśli tworzysz nowy obiekt, wszelkie domyślne wartości początkowe). Myślę, że to oddziela obawy lepiej niż opcja nr 1, która łączy dane "modelowe" i dane "wsparcia".

Ale jak zauważyłeś, powoduje to dodatkowe połączenia, a jeśli są bardzo liczne, może znacznie spowolnić stronę. (lub zwiększyć złożoność, przy dużej formie z dużą ilością zależnych pól, zamawianie może stać się ważne).

Zazwyczaj to, że serwer zapewnia "połączone" api (na przykład /editor/prepare-all), jednocześnie dostarczając małe kawałki (na przykład /editor/prepare-dropdown-1, /editor/prepare-dropdown-2). Kiedy twój edytor się załaduje, użyjesz połączonego; jeśli istnieją zależności między polami, możesz zażądać tylko danych dla pól zależnych (np. /editor/prepare-dropdown-2?dropdown1-value=123). Wierzę, że ma to niewielki wpływ na złożoność serwera.