Pochodzę z używania ASP.NET MVC / Web API, a teraz zaczynam używać Angulara, ale nie wiem, jak należy je mieszać.
Czy po używaniu Angulara koncepcje po stronie serwera MVC nadal zapewniają jakąkolwiek wartość? A może powinienem używać interfejsu API sieci Web wyłącznie do pobierania danych dla kątowych wywołań HTTP?
Pomocne byłyby wszelkie wskazówki dotyczące przejścia faceta ASP.NET MVC do Angular
Odpowiedzi:
Czysty internetowy interfejs API
Kiedyś byłem dość hardkorowy z ASP.NET MVC, ale odkąd spotkałem Angulara, nie widzę jednego powodu, dla którego miałbym używać dowolnego frameworka generowania zawartości po stronie serwera. Pure Angular / REST (WebApi) daje bogatszy i gładszy wynik. Jest znacznie szybszy i umożliwia tworzenie witryn internetowych, które są bardzo zbliżone do aplikacji komputerowych, bez żadnych ciekawych hacków.
Angular ma trochę krzywej uczenia się, ale gdy Twój zespół go opanuje, zbudujesz znacznie lepsze witryny w krótszym czasie. Głównie ma to związek z faktem, że nie masz już wszystkich tych (mniej) problemów ze stanem.
Na przykład wyobraź sobie formularz kreatora z dowolną tradycyjną strukturą po stronie serwera. Każda strona musi zostać zweryfikowana i przesłana osobno. Być może zawartość strony zależy od wartości z poprzedniej strony. Być może użytkownik nacisnął przycisk Wstecz i ponownie przesyła poprzedni formularz. Gdzie przechowujemy stan klienta? Wszystkie te komplikacje nie istnieją podczas korzystania z Angular i REST.
Więc ... przejdź na ciemną stronę ... mamy ciasteczka.
AngularJS jest bardziej związany z paradygmatem aplikacji jednostronicowych i jako taki nie korzysta zbytnio z technologii po stronie serwera, które renderują znaczniki. Nie ma technicznego powodu, który wykluczałby używanie ich razem, ale w praktycznym sensie, dlaczego miałbyś to robić?
SPA pobiera potrzebne zasoby (widoki JS, CSS i HTML) i działa samodzielnie, komunikując się z powrotem do usług w celu wysyłania lub pobierania danych. Tak więc technologia po stronie serwera jest nadal niezbędna do świadczenia tych usług (a także innych środków, takich jak uwierzytelnianie i tym podobne), ale części renderujące są w dużej mierze nieistotne i niezbyt przydatne, ponieważ jest to powielenie wysiłków, z wyjątkiem MVC to robi po stronie serwera, a Angular robi to na kliencie. Jeśli używasz Angulara, chcesz, aby był on dostępny na kliencie, aby uzyskać najlepsze wyniki. Możesz tworzyć formularze post HTML w Angular i pobierać częściowe widoki z akcji MVC, ale straciłbyś najlepsze i najłatwiejsze funkcje Angular i utrudniał Ci życie.
MVC jest dość elastyczny i można go używać do obsługi połączeń z aplikacji SPA. Jednak WebAPI jest lepiej dostrojone i nieco łatwiejsze w użyciu dla takich usług.
Napisałem wiele aplikacji AngularJS, w tym kilka, które migrowały z wcześniej istniejących aplikacji WebForms i MVC, a aspekt ASP.NET ewoluuje w kierunku platformy do dostarczania aplikacji AngularJS jako rzeczywistego klienta i do hostowania warstwy aplikacji klient komunikuje się przez REST (używając WebAPI). MVC to dobry framework, ale zwykle nie ma pracy w tego rodzaju aplikacjach.
Aplikacja ASP.NET staje się kolejną warstwą infrastruktury, gdzie jej obowiązki ograniczają się do:
Kolejną wielką zaletą SPA jest to, że może zwiększyć przepustowość Twojego zespołu. Jedna grupa może wysadzać usługi, podczas gdy druga leży w aplikacji klienta. Ponieważ możesz łatwo odgrywać lub mockować usługi REST, możesz mieć w pełni działającą aplikację kliencką na usługach pozorowanych i zamieniać się na prawdziwe, gdy są gotowe.
Musisz zainwestować z góry w Angular, ale to się opłaca. Ponieważ znasz już MVC, masz przewagę nad niektórymi podstawowymi koncepcjami.
To zależy od projektu, nad którym pracujesz.
Jeśli angularJS jest dla Ciebie czymś nowym, wolałbym wybrać mały projekt o niskim ryzyku / presji, aby rozpocząć i upewnić się, że nauczysz się robić rzeczy we właściwy sposób (widziałem wiele projektów wykorzystujących Angularjs nieprawidłowo z powodu presji, terminów ... brak czasu na nauczenie się go w odpowiedni sposób, np. za pomocą JQuery lub dostęp do DOM wewnątrz kontrolerów itp.).
Jeśli projekt jest projektem typu green field i masz pewne doświadczenie w AngularJS, sensowne jest porzucenie ASP.net MVC i po stronie serwera postawienie na czysty REST / WebAPI.
Jeśli jest to istniejący projekt, możesz wybrać złożony podzbiór funkcji i zbudować tę stronę jako oddzielną aplikację angularJS (np. Twoja aplikacja składa się z dużej liczby standardowych stron opartych na maszynce Razor, ale potrzebujesz zaawansowanego edytora / strona, która mogłaby być elementem docelowym do zbudowania za pomocą AngularJS).
Możesz użyć frameworka Angular do programowania frontendu, tj. Do tworzenia widoków. Zapewnia solidną architekturę, a kiedy już się nauczysz, odkryjesz jej zalety w porównaniu z silnikiem widoku brzytwy Asp.net MVC. Aby pobrać dane, musisz użyć WebAPI, a projekt ASP.Net MVC obsługuje teraz kontrolery WebAPI i MVC. Możesz zapoznać się z poniższym linkiem Zacznij od tworzenia aplikacji Angular i ASP.Net MVC.
http://hive.rinoy.in/angular4-and-asp-net-mvc-hybrid-application/
Obecnie dostępne są dwie struktury do tworzenia komponentów interfejsu użytkownika dla aplikacji kątowych. Użyłem obu tych frameworków w jednym z projektów kątowych, nad którymi pracowałem.
Materiał https://material.angular.io/