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?
- Rejestracja:prawie 4 lata
- Ostatnio:ponad rok
- Postów:86
0
- Rejestracja:prawie 14 lat
- Ostatnio:4 dni
- Postów:525
0
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
edytowany 1x, ostatnio: mar-ek1
- Rejestracja:około 3 lata
- Ostatnio:ponad rok
- Postów:2310
0
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.
- Rejestracja:prawie 22 lata
- Ostatnio:około 7 godzin
- Lokalizacja:Kraków
- Postów:1114
0
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.
edytowany 2x, ostatnio: neves
- Rejestracja:około 6 lat
- Ostatnio:około 6 godzin
0
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
edytowany 2x, ostatnio: obscurity
- Rejestracja:około 12 lat
- Ostatnio:około 8 godzin
- Postów:1431
0
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
- screenshot-20230309155525.png (193 KB) - ściągnięć: 6
edytowany 1x, ostatnio: Saalin
LukeJL
swoją drogą fajnie byłoby poszukać jakichś starych artykułów czy dyskusji na Hacker News i się pośmiać z ludzi zachwycających się Backbonem czy czymś innym prehistorycznym. A potem ekstrapolować to na ludzi, którzy się zachwycają obecnymi frameworkami i nie zdają sobie sprawy z tego, że za 5-10 lat będzie to nadawać się jedynie do muzem.
- Rejestracja:prawie 4 lata
- Ostatnio:ponad rok
- Postów:86
0
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
edytowany 1x, ostatnio: Michał Jasiński
- Rejestracja:ponad 6 lat
- Ostatnio:około 7 godzin
- Postów:664
0
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".
- Rejestracja:prawie 15 lat
- Ostatnio:około 2 godziny
- Lokalizacja:Laska, z Polski
- Postów:10056
0
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.
edytowany 1x, ostatnio: Riddle
nie chodzi o wzorzec MVC a o ASP.NET MVC - to platforma oparta o ten wzorzec. ASP.NET Web Api to nazwa "konkurencyjnej" platformy; patrz na dział w którym jesteś. W zasadzie webapi to mvc tylko "widokiem" jest odpowiedź api zamiast htmla
po prostu zapomnijmy już o .net framework, od .net 5 powrócił ład. Swoją drogą tu kolejny przykład świetnego nazewnictwa - nazywając framework ".net framework", jak komuś niewtajemniczonemu powiesz że .net framework odchodzi w zapomnienie to myśli że chodzi o cały framework .net, a tu chodzi tylko o framework .net framework :D Chyba dlatego pośmiertnie dali mu drugi przydomek "classic"
- Rejestracja:około 3 lata
- Ostatnio:około 5 godzin
- Postów:816
0
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.
- Rejestracja:około 6 lat
- Ostatnio:10 miesięcy
- Postów:111
0
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? 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?
- Rejestracja:około 6 lat
- Ostatnio:około 6 godzin
0
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
edytowany 3x, ostatnio: obscurity
- Rejestracja:prawie 7 lat
- Ostatnio:około 10 godzin
- Postów:77
1
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.
- Rejestracja:około 3 lata
- Ostatnio:około 5 godzin
- Postów:816
3
Przypomniał mi się post traktujący o ASP.NET MVC http://commitandrun.pl/2016/05/30/Brutalne_prawdy_o_MVC/