powoli zabieram się za pisanie (w ramach inżynierki) aplikacji webowej. Mam do Was następujące pytanie - co lepiej wybrać, jeżeli i tak będę się tego uczył powiedzmy od podstaw: ASP.NET 3.5 czy ASP.NET MVC 2? Pisanie w tym pierwszym jest teoretycznie prostsze, jest dużo dokumentacji i książek także po polsku (co dla mnie również jest ważne). MVC to zupełnie inne podejście, wydajniejszy kod, lepsze zarządzanie nim, ale brakuje choćby jednej pozycji pl na jego temat, ponadto trzeba pisać więcej kodu (co nie uważam za wadę, ale jednak).
Co byście doradzili? Od czego lepiej zacząć? Co będzie milej widziane podczas obrony? Wiele firm cały czas opiera się jednak na starszej wersji, MVC to pewnie niedaleka, ale jednak przyszłość w naszym kraju.
jeśli pierwszy raz masz odczynienia z asp.net wg lepszym wyborem będzie skorzystanie z asp.net forms. sam pisałem projekt licencjacki ucząc się asp.net. Jeśli kiedykolwiek programowałeś Windows Forms to tutaj niewiele się zmienia, zamysł tworzenia aplikacji jest podobny.
Programowałem sporo w Windows Forms, dlatego właśnie wolę starszą wersję (mam też w… dużo książek na ten temat). Jednak MVC to pewnie przyszłość i boję się, że ktoś mi zarzuci, że nie spróbowałem czegoś nowszego, ambitniejszego. Ale chyba jednak zacznę od na asp.net forms. Dwa-trzy miesiące może wystarczą na jakieś w miarę rozsądne poznanie tego, mam nadzieję
Generalnie rzecz biorąc jeżeli będziesz umiał dobrze asp.net zwyczajny to bez problemu uda Ci się przejść na MVC. Jeżeli będziesz tak pisał aplikacje aby była wielowarstwowa(np. DAL - Data Access Layer) to tak naprawdę potem zmienią się tylko główne pojęcia. Pod wartwą Model będziesz miał klasy mapujące bazę danych, pod wartwą Controllera jakiś ADO, a pod View będziesz miał html albo aspx.
Obserwując rynek programistów webowych C# naprawdę żadko się spotkałem się, żeby szukali ASP.NET MVC w porównaniu do asp.net oldschool-owego .
Że co? Chyba nie rozumiesz koncepcji MVC. Jakie ADO w kontrolerze?
MVC i WebForms są tak podobne jak wiertarka i lodówka - obie na prąd.
Bo MVC ma dwa lata, a WebFormsy dużow więcej, siłą rzeczy są więc popularniejsze. Jest do nich więcej bibliotek zewnętrznych firm i powstało w nich wiele systemów, które nadal trzeba utrzymywać. A poza tym w ASP.NET powstają głównie aplikacje intranetowe, a w sieci LAN nie trzeba się tak ograniczać z przesyłem danych. Ale np. u mnie w firmie każdy nowy projekt tworzony jest właśnie w MVC.
Ideą WebFormsów było umożliwienie łatwego programowania na zasadzie 3D (drag, drop & don’t think). Problem w tym, że o ile da się to wykonać dla aplikacji desktopowych, to dla webowych nie bardzo. Tu nie ma możliwości łatwego przechowania ogromnej ilości danych w pamięci, a programowanie zdarzeniowe tylko utrudnia tworzenie i debugowanie aplikacji.
ASP.NET to technologia tworzenia aplikacji webowych na platformie .NET.
MVC to wzorzec projektowy, w którym każda literka oznacza warstwę o określonej odpowiedzialności.
View - to co widzi użytkownik, czyli najczęściej interfejs graficzny;
Model - domena, logika biznesowa, obsługa źródeł danych, itd - zwykle warstwy typu Domain, BusinnessLogic, DataAccessLayer, itd. z aplikacji wielowarstwowych;
Controller - obsługa żądań użytkowników - czyli wykrycie np. kliknięcia w przycisk, wywołanie operacji z Modelu, przekierowanie do odpowiedniego Widoku. TYLKO tyle (dlatego wiele przykładów i tutoriali z netu jest złych). Na żadne ADO nie ma tu miejsca.
To co nazywasz “zwyczajnym asp.net”, to o ile dobrze Cie rozumiem są WebFormsy.Tutaj interfejs użytkownika (pliki aspx) i obsługa ich żądań (code behind) siedzi w jednej warstwie. Owszem, możesz dodać inne warstwy, ale tamte dwie rzeczy nadal będą obsługiwane w jednej.
Jak widać to dwie zupełnie inne koncepcje.
No, to struktura plików aplikacji. Czy to MVC czy WebForms są jakieś pliki w projekcie, pod tym względem się faktycznie nie różnią. A o co chciałeś spytać?
Nie wiem czy pytasz, czy ironizujesz. Ja w każdym razie nie znam takiej.
Ładowanie danych do ViewState obciąża łącze i zwiększa rozmiar strony. Ładowanie do Session obciąża serwer. A wszystko to trwa.
Ja nie pamiętam, kiedy ostatnio używałem design view. Nie używam go z następujących przyczyn:
Jest bardzo powolny i zamula sprzęt.
Zbyt często bywa niestabilny.
Większość szybciej napiszę coś w kodzie aspx z Intellisense.
Jest niefunkcjonalny - to co wyświetla nie jest zgodne z żadną przeglądarką, nawet IE, więc to co tu widzę, nie odpowiada niczemu, co może zobaczyć użytkownik. Do tego nie kuma CSSów w plikach kontrolek.
Nie znam też nikogo, kto by go używał. Może studenci.
W MVC nie masz zdarzeń, tylko Request - Response. Jest prosto i przejrzyście. Każdy błąd wyłapie się szybko.
W WebForms masz cykl zdarzeń strony i kontrolek, który jest skomplikowany i błędogenny. Tworzona jest strona, wypełniane są jakieś dane, później generowany jakiś HTML, coś renderowane - nad niczym nie panujesz. W efekcie, gdy zauważysz, że jakąś część strony wygenerowała się niepoprawnie, to nie wiesz, czy to przez, to że w jakimś inicie ktoś programowo dodaje jakiś HTML, który powoduje rozjechanie layoutu, czy gdzieś nie wykonało się bindowanie danych, bo w jakimś innym zdarzeniu źródło zostało wyczyszczone, itd., itp. Więc gdzie w tym cyklu wstawić breakpointa?
A w MVC wszystko, poza layoutem strony przetestujesz bez uruchamiania serwera WWW.
Reasumując.
MVC daje:
lżejsze strony wynikowe;
możliwość wykluczenia JavaScript;
nad poszczególnymi warstwami programiści mogą pracować oddzielnie;
łatwiej testować, pisać testy jednostkowe, można także zastosować TDD, ponadto testowanie nie wymaga uruchamiania serwera, jak to jest w przypadku WebForms;
przejrzystą strukturę projektu - w WebForms te same klasy odpowiadają za wyświetlanie danych i obsługę żądań użytkowników, zupełnie inaczej niż tutaj;
szablony dla klas kontrolerów i widoków - szybkie tworzenie;
tworzenie silnie typowanych widoków (powiązanych z klasami modelu) dla odpowiednich operacji (przeglądanie, dodawanie, edycja… danych);
WebForms daje:
dużo gotowych kontrolek*;
znana, popularna i dobrze udokumentowana technologia;
łatwiej korzystać z AJAXa;
w zasadzie nie trzeba się babrać w JavaScript*.
*Ale i to nie do końca - kontrolki, czy to standardowe, czy nawet komercyjne są przystosowane do takiego zachowania, jakie wymyślili ich twórcy. Jeśli trzeba coś zmienić, coś dostosować do potrzeb naszej aplikacji bardzo często oznacza to duży nakład pracy, nawet taki, że łatwiej byłoby to zrealizować samodzielnie, bez “pomagania” sobie gotowymi kontrolkami.
wielkie dzięki za wyjaśnienie Teraz widzę, że mvc jest bardzo ciekawym szkieletem Ogólnie wiedziałem na czym polega mvc z javy ale sądziłem, że mvc ma odpowiedniki w tradycyjnym asp. Możliwość testowania bez serwera to też bardzo ważny plus
Może jak znajdę czas to pouczę się mvc. pozdrawiam.
Wiele firm cały czas opiera się jednak na starszej wersji, MVC to pewnie niedaleka, ale jednak przyszłość w naszym kraju.