Czy WebApi wypiera MVC

Cześć, zastanawiam się czy aplikacje działające wg wzorca MVC są obecnie wypierane przez WebApi. Innymi słowy czy w nowo tworzonych rozwiązaniach unika się raczej MVC?

Jeżeli piszesz aplikację w ASPNET Core, to tak naprawdę jeden projekt jest modułowy i od Ciebie zależy jak go skonfigurujesz - czy będzie tam API, MVC, Razor Pages, Blazor, SignalR czy wszystko na raz albo w dowolnej kombinacji to zależy od Ciebie.
Pisze się nadal aplikacje w MVC jeżeli nie potrzeba nam mocno dynamicznego contentu.

EDIT: Kurde, przeczytałem w tytule "wspiera" zamiast "wypiera" - ZIGNORUJCIE MOJĄ ODPOWIEDŹ :D

Michał Jasiński napisał(a):

Cześć, zastanawiam się czy aplikacje działające wg wzorca MVC są obecnie wypierane przez WebApi. Innymi słowy czy w nowo tworzonych rozwiązaniach unika się raczej MVC?

Mniej chodzi o sam wzorzez MVC, tylko o fakt jednowartwowej / dwuwarstwowej, tak rozumiem twoje pytanie.
Apki webowe się nie zamykały / nie zamykają na MVC, jest też MVVC i inne.

Rozumiem (po części) względy jakie za tym przemieszczeniem (o jakim piszesz) stoją, ale wielokrotnie to jest bardzo kosztowne nie tylko w etatach, ale w błędach i ograniczeniach interfejsowania, np bardzo wiele błędów walidacji jakie z czasem wchodzą do projektu podczas rozwoju. Front zaakceptował, ale backend w nowszej wersji na nowe wymagania, lecą jakies chore komuniakty itd ... widziałem już zrzuty wyjatków SQL-owych, martwe pętle z których nie ma wyjścia, miała być wydajność, jest koszmar.

Zależy od kontekstu (czego projekt potrzebuje i jakie zasoby ludzkie mamy do dyspozycji), jednak web api zapewnia większą elastyczność i możliwości późniejszego rozwoju.Także to nie jest kwestia unikania, webapi jest po prostu bardziej perspektywiczne.

Gdyby zasoby ludzkie nie były problemem, to nawet dla statycznych stron bym preferował użycie od razu webapi.

Tak, moim zdaniem są wypierane. Dużo łatwiej znaleźć frontendowca i przede wszystkim oddzielić front od backendu i podzielić backend na mikroserwisy z których teoretycznie każdy może być pisany w innym języku (jeszcze czegoś takiego co prawda nie spotkałem).
Nie widziałem już sporo czasu nowej aplikacji w MVC

Nie widziałem jeszcze komercyjne aplikacji w ASP .NET MVC ;) Już 5 lat temu nowe rzeczy* były pisane jako API + front w JS, tendencja się nie zmieniła.

* w sumie nie nowe też, w jakiś prehistorycznych frameworkach JS, pic related

Tak podejrzewałem, że ze względu na możliwość rozbudowy aplikacji jak i wyraźne oddzielenie widoku od warstwy domenowej raczej odchodzi się od MVC w nowo tworzonych projektach.
Dzięki za komentarze i podpowiedzi w tym temacie

Zależy do czego. W jednej z firm robiliśmy tak, że aplikacja dla użytkownika była API + frontend (bo to lepiej działa i wygląda), ale był też panel admina (do używania przez właściciela aplikacji tudzież jej supportu) gdzie był najczęściej jakiś brzydki, naklepany przez backendowców konfiguracyjny CRUD + ew. jakieś przydatne rzeczy typu lista użytkowników, statystyki użycia - to zdecydowanie szybciej i prościej było napisać "tradycyjnie".

Michał Jasiński napisał(a):

Cześć, zastanawiam się czy aplikacje działające wg wzorca MVC są obecnie wypierane przez WebApi. Innymi słowy czy w nowo tworzonych rozwiązaniach unika się raczej MVC?

MVC to rodzaj architektury, a WebApi to masz na myśli....? Co konkretnie?

Wzorzec MVC został wymyślony przez gościa Trygve Reenskaug i pierwszy raz użyty w SmallTalku. Chodziło w nim po prostu o odseparowanie inputu od outputu i przetwarzania danych; ale niestety potem został przerobiony na jakiś dzwiny frankestein w którym cały page miał trzy warstwy Controller/Model/View - teraz jak ktoś mówi że ma MVC to to znaczy tylko tyle że ma nadrzędne foldery Model, View, Controller w aplikacji i praktycznie 0 enakspulacji, bo i tak wszystkie warstwy wiedzą o wszystkich. Ten frankenstein był zaadoptowany przez frameworki takie jak Laravel, Rails i Symfony; co było poważnym błędem. Niektórzy zaczęli to zauważać że to był błąd i zaczynają odchodzić od tego.

W dobie frameworków SPA ASP.NET MVC nie ma sensu. Na początku (pamiętam te czasy jak przechodziłem z Web Forms na MVC) był rewolucją, która w końcu oddzieli warstwę prezentacji od logiki aplikacji. Rzeczywistość zweryfikowała to założenie na niekorzyść frameworka. Niestety, ale jak ktoś pozwala ładować kod C# do widoków to prędzej czy później to zawsze się źle kończy. Do tego widoki w ASP.NET MVC to wciąż generowanie UI po stronie serwera. Współczesne frameworki SPA jak Angular czy React pozwalają na dużo więcej i łatwiej się utrzymuje kod, gdy frontend jest napisany w innej technologii niż backend.

iteredi napisał(a):

To ciekawe że zawsze robi się już aplikacje z podziałem na frontend i backend. Nie ma już zapotrzebowania na aplikacje renderowane w całości po stronie serwera?

podział na backend i frontend nie eliminuje możliwości renderowania po stronie serwera. Większość dużych serwisów prerenderuje treść pierwszej strony po stronie serwera i dopiero kolejne podstrony są dynamiczne.

Czy programiści i tak w przypadku statycznych stron uderzają 100 razy pod różne endponty żeby finalnie wyświetlić każdemu użytkownikowi to samo?

wystarczy użyć GraphQL i możesz mieć zawsze jedno zapytanie pod jeden endpoint

Innymi słowy czy w nowo tworzonych rozwiązaniach unika się raczej MVC?

Architektura jest pochodną wymagań a nie na odwrót.

Przykładowo, jeśli mowa o punktach końcowych pasywnych protokołów SSO czy integracji z bramkami usług płatności albo epuap itp wymagających przekierowań między domenami, na ściśle wyspecyfikowane adresy, w ściśle określony sposób, to często łatwiej jest to zrobić w takim fragmencie technologii który renderuje od razu widok z serwera.

Tam z kolei gdzie użytkownik kręci się po widokach w ramach jednej aplikacji, wydzielony frontend może być łatwiejszy.

W net od zawsze można w jednej aplikacji mieć wszystkie możliwe typy handlerów, byle tylko na rozłącznych routach.

Przypomniał mi się post traktujący o ASP.NET MVC http://commitandrun.pl/2016/05/30/Brutalne_prawdy_o_MVC/