ASP.NET - web forms (i MVC) - kilka pytań

Mam do zrobienia mały projekt zaliczeniowy w ASP.NET, tyle że niestety w starej wersji, czyli WebForms i chyba we frameworku 3.5 (czytałem, że są aż cztery wersje ASP.NET - od najstarszych: WebForms, WebPages, MVC i ostatnio Core - i nie bardzo wiem czym się różnią). W WebFormsach chyba już dziś nikt nie pracuje, czy może się mylę? Właściwie widuję tylko oferty w MVC.

Chciałem zapytać o WebForms-y:

• czy trudno jest przerobić gotową aplikację w WebForms (tradycyjną lub na template-ach Razor 3) na ASP.NET MVC ? (czy to jest raczej pisanie wszystkiego od początku)
• czy aplikacja ASP.NET jest w formie skompilowanej i jak w skrócie wygląda deployment takich stron na WebFormsach?
• jak duża jest różnica między WebForms a MVC? (wiem z grubsza jak wygląda strona wg. wzorca model-widok-kontroler (choć nigdy nie robiłem nic w platformie .NET), natomiast wyczytałem, że WebForms jest oparty na gotowych kontrolkach, coś jak WinForms dla desktopu).
• czy warto jeszcze rzeźbić w WebFormsach, czy prosić prowadzącego, żeby zgodził się na MVC?

• To jest całkowicie inne podejście. Gotowe kontrolki vs czysty HTML etc... ale co za tym idzie większa kontrola nad kodem, lżejsze strony i warstwy (jeżeli dobrze je zrobisz rzecz jasna) więc również prostsze testowanie;
• Generalnie robi się Build -> Publish i wyklikuje w kreatorze ale można również przerzucić folder z projektem na żywca;
• Napisałem w punkcie pierwszym;
• MVC koniecznie; WebForms to podobnie jak WinForms stare technologie używane w starych projektach; Wszystko nowe pisane jest w MVC, a na desktop w róznych WPF'ach etc...

W WebFormsach chyba już dziś nikt nie pracuje, czy może się mylę?

Pracuje się ale nie w nowych projektach tylko utrzymując coś co ileś tam lat już działa.

Dzięki za info!

Szczurek1

A co sądzicie o ASP.NET CORE? Przyjmie się? I jakie to wnosi nowości, zmiany? Wiem, że NET Core to jest crossplatformowe rozwiązanie Microsoftu. Ale co to zmienia w web devie ??

I co to jest u licha vNEXT (coś takiego widziałem również)?

Przyjmie się - pytanie jak bardzo. Czy zatwardziali użytkownicy nie-ASP na niego przejdą to nie wiem, ale dla obecnych jest trochę fajnych nowych rzeczy. Zmienia trochę samego ASP.NET MVC, prócz cross-platform dodaje trochę nowinek, ale ogólna koncepcja jest ciągle taka sama.

ASP.NET vNext to stara nazwa ASP.NET 5, obecnie nazwanego ASP.NET Core 1.0.

ASP.NET vNext to stara nazwa ASP.NET 5, obecnie nazwanego ASP.NET Core 1.0.

Można się pogubić w tym szybko.

Jeszcze dwa pytania:

1. Czy duże są różnice między MVC 4 a MVC 5? (mam dwie książki do MVC 4 i zastanawiam się czy "nie będę z technologią w lesie" jak z nich będę korzystał).

2. I czy MVC 6 wnosi jakieś warte odnotowania zmiany?

DZIĘKI !

Zakręcony Szczurek napisał(a):

Chciałem zapytać o WebForms-y:

• czy trudno jest przerobić gotową aplikację w WebForms (tradycyjną lub na template-ach Razor 3) na ASP.NET MVC ? (czy to jest raczej pisanie wszystkiego od początku)

To zależy, czy cała logika biznesowa, dostęp do danych, itd. jest wepchnięte w WebFormsy, czy istnieje sensowny podział na warstwy i WebFormsy zajmują się tylko wyświetlaniem. WebFormsy to technologia RAD (Rapid Application Destruction), wyposażona np. w takie cuda jak osadzane w widoku zintegrowane źródła danych (np. w elemencie aspx podajesz nazwy procedur do pobierania/wstawiania/usuwania danych).

• czy aplikacja ASP.NET jest w formie skompilowanej i jak w skrócie wygląda deployment takich stron na WebFormsach?

Kod aplikacji (C# czy w czym tam piszesz) jest w formie plików dll, natomiast pliki ASPX są po prostu "luzem". Czyli generalnie jest tak jak w MVC.

• jak duża jest różnica między WebForms a MVC? (wiem z grubsza jak wygląda strona wg. wzorca model-widok-kontroler (choć nigdy nie robiłem nic w platformie .NET), natomiast wyczytałem, że WebForms jest oparty na gotowych kontrolkach, coś jak WinForms dla desktopu).

Tak jest, tylko nie ma problemu, żeby sobie aplikację WebForms też oprzeć o jakiś wzorzec. Może nie MVC, ale MVP się nieźle sprawdza.

• czy warto jeszcze rzeźbić w WebFormsach, czy prosić prowadzącego, żeby zgodził się na MVC?

Dziwne jest uczenie WebFormsów w obecnych czasach, widać prowadzący się zatrzymał w rozwoju jakieś 10 lat temu.

Jeszcze dwa pytania:

1. Czy duże są różnice między MVC 4 a MVC 5? (mam dwie książki do MVC 4 i zastanawiam się czy "nie będę z technologią w lesie" jak z nich będę korzystał).

Podstawy są takie same, ja uczyłem się MVC 1.0 i niektóre elementy są identyczne :-)

2. I czy MVC 6 wnosi jakieś warte odnotowania zmiany?

Tak, choćby tag helpers, zmianę we ViewBagu, Dependency Injection.
I już nie nazywa się ASP.NET MVC 6.0, teraz nazywa się ASP.NET MVC Core 1.0.

somekind napisał(a):

Kod aplikacji (C# czy w czym tam piszesz) jest w formie plików dll, natomiast pliki ASPX są po prostu "luzem". Czyli generalnie jest tak jak w MVC.

W ASP.NET Core w ogóle prawie wszystko jest luzem jako pliki .cs, a kompiluje się na bieżąco.

Dziwne jest uczenie WebFormsów w obecnych czasach, widać prowadzący się zatrzymał w rozwoju jakieś 10 lat temu.

Ja ze swoich zajęć wyrzucałem WebForms stopniowo - kiedyś była prawie połowa zajęć na WebForms, potem dwa zajęcia, teraz okrągłe zero. Tylko wspominam o ich istnieniu ;-)

W ASP.NET Core w ogóle prawie wszystko jest luzem jako pliki .cs, a kompiluje się na bieżąco.

Jaki to ma sens? Nie ma to negatywnego wpływu na wydajność?

A co do WebForms już je szczęśliwie porzuciłem :) i działam w MVC 4 w VS 2015 Update 3.

Bogaty Rycerz

A czy MVC Core 1.0 jest kompatybilne wstecznie z MVC 5 / 4 ?? (czytałem, że są jakieś nowe środowiska uruchomieniowe).

Bogaty Rycerz

Jaki to ma sens? Nie ma to negatywnego wpływu na wydajność?

I tak po pierwszym requeście skompilowana wersja będzie cache'owana, więc nie ma to większego wpływu.

A czy MVC Core 1.0 jest kompatybilne wstecznie z MVC 5 / 4 ?? (czytałem, że są jakieś nowe środowiska uruchomieniowe).

Core może być uruchamiane zarówno na nowym .NET Core jak i na starym .NET Frameworku.

Odnośnie wyszukiwania na stronie z bazą danych ( kod ze strony: http://lukaszkosiorowski.pl/programowanie/net/asp-mvc/10-wyszukiwanie-danych-kurs-asp-net-mvc-5/ ):

[HttpPost]
public ActionResult Index(SzukajAuta Model)
{
    var cars = from i in db.Cars
                select i;

    if (Model != null)
    {
        cars = from i in db.Cars
                where i.Model.Equals(Model.ModelZnajdz)
                && i.Brand.Equals(Model.BrandZnajdz)
                select i;
    }

    return View(cars.ToList());
}

...czy to jest dobra praktyka? Najpierw z bazy wyciągamy wszystkie samochody, a później (jeśli przez POST przekażemy frazę wyszukiwania) to jeszcze raz odwołujemy się do bazy i wybieramy tym razem auto konkretnego modelu i marki. Wydaje mi się, że powinno być albo jedno albo drugie (odpowiednia konstrukcja if-else). Czy może takie "zapytanie" nie jest jednoznaczne z odwołaniem się do bazy danych? A odwołanie odbywa się dopiero przy zwracaniu widoku return.View....?

Druga sprawa, tu jest wyszukiwanie po modelu i marce. Co jeśli mamy "wyszukiwanie zaawansowane" i pól jest kilkanaście (np. cena od do, rocznik od do, pojemność silnika itd itd.) - czy tak samo buduje się zapytanie w LINQ i czy to na dłuższą metę "nie zabije" bazy danych (tak złożone zapytania)? Gdzieś czytałem, że powinno się "zapytywać bazę" tylko o pola/wartości które użytkownik w danym momencie wpisze w wyszukiwarce, a nie wszystkie.

Bogaty Rycerz

Bogaty Rycerz napisał(a):

Najpierw z bazy wyciągamy wszystkie samochody, a później (jeśli przez POST przekażemy frazę wyszukiwania) to jeszcze raz odwołujemy się do bazy i wybieramy tym razem auto konkretnego modelu i marki. Wydaje mi się, że powinno być albo jedno albo drugie (odpowiednia konstrukcja if-else). Czy może takie "zapytanie" nie jest jednoznaczne z odwołaniem się do bazy danych? A odwołanie odbywa się dopiero przy zwracaniu widoku return.View....?

Odpytanie bazy danych odbywa się dopiero w momencie wywołania cars.ToList(). Niemniej jednak ja w takiej sytuacji raczej użyłbym jakiegoś if-else, żeby wyraźnie było widać, że rozróżniam dwa zachowania w kodzie, a nie "nadpisuję" jedną definicję cars inną.
Poza tym, ten blog kłamie chociażby tutaj:

Wysyłając formularz metodą GET (method=”get”), dane są doklejane do adresu URL, np. www.jakasstrona.pl?imie=Lukasz&wiek=99, każdy może podejrzeć i podmienić z łatwością te dane. Używając natomiast metody POST, ukrywamy dane, których teoretycznie nie da się podmienić, a przesyłaną za pomocą globalnej tablicy.

Przed czym on chce zabezpieczać? Żeby użytkownik sobie przypadkiem ręcznie nie wpisał parametrów wyszukiwania? To jest chore!

A także tutaj:

Warto dodać, że obie akcje Index , są obsługiwane przez jeden widok.

Nieprawda, akcje są obsługiwane przez jeden kontroler. Widok jest efektem wywołania jednej z nich.

I promuje złe praktyki:

• nazywanie zmiennych wielką literą;
• mieszanie nazewnictwa polskiego i angielskiego;
• niepoprawne używanie HTTP post - to służy do zapisu danych, wyszukiwanie ze względów praktycznych powinno odbywać się getem.

Generalnie jego autor sprawia wrażenie bycia jakimś newbie, który coś tam już zlepił ze StackOverflow i całkiem nieźle idzie mu już programowanie przez koincydencję. Niestety wpadł na pomysł dzielenia się swoimi przemyśleniami ze światem, a Ty miałeś nieszczęście w to wdepnąć. :(

Druga sprawa, tu jest wyszukiwanie po modelu i marce. Co jeśli mamy "wyszukiwanie zaawansowane" i pól jest kilkanaście (np. cena od do, rocznik od do, pojemność silnika itd itd.) - czy tak samo buduje się zapytanie w LINQ i czy to na dłuższą metę "nie zabije" bazy danych (tak złożone zapytania)? Gdzieś czytałem, że powinno się "zapytywać bazę" tylko o pola/wartości które użytkownik w danym momencie wpisze w wyszukiwarce, a nie wszystkie.

No tak, ale on nie pobiera wszystkich rekordów tylko je filtruje. To akurat jedyna niespieprzona rzecz znajdująca się pod tym linkiem.

Dzięki za dokładne wyjaśnienie.

Autor pisze (i daje) link że bazował na tutorialu ze strony MSDN. Z daleka widać, że autor nie ma dużego doświadczenia, ale ja mam jeszcze mniejsze :) Tekst jest przystępnie napisany (i jeden z pierwszych jakie wyskoczyły w Googlu), dlatego go wybrałem jako na tutek "na start".

@somekind: Ja znów odnośnie architektury. :)
Rozumiem, że w kontekście Twoich postów z innego tematu na 4p o MVC rozwiązanie zaprezentowane na StackOverflow pod tym linkiem:
http://stackoverflow.com/questions/5049363/difference-between-repository-and-service-layer, gdzie użytkownik LukLed proponuje przepływ jak poniżej, również nie jest dobrą praktyką?

Views <- Controllers -> Service layer -> Repository layer -> EF -> SQL Server

**Service layer -> Repository layer -> EF **This part operates on models.

Views <- Controllers -> Service layer This part operates on view models.

@MMSz - sama idea oddzielenia kontrolerów od warstwy danych poprzez serwisy, które także z jednej strony wystawiają API oparte na viewmodelach dla kontrolerów, a z drugiej strony operują na modelu danych (persistence model, nie model), to jest coś, co bardzo lubię i promuję. Generalnie to, co opisał ten gość ma sens - z wyjątkiem tych repozytoriów, które standardowo niczego nie dają, i są jedynie kupą dobrej, nikomu niepotrzebnej roboty. Ludzie je piszą, bo ktoś im kiedyś tak pokazał, bez zastanowienia się, czy mają z tego w ogóle jakiś zysk.
A jest wręcz przeciwnie - bo jak się opakuje kontekst ORMa w repozytoria, to aby móc wykonać jedną transakcję na kilku repozytoriach, trzeba także zaimplementować UoW, a zrobienie tego prawidłowo to coś, co powala 90% programistów. A przecież gdyby operować bezpośrednio na ORMie, byłoby łatwiej, bo i UoW i generyczne repozytorium już mamy.

@somekind, dzięki wielkie za odpowiedzi tutaj i w bliźniaczym temacie o ASP.NET MVC.

Jeszcze jedna rzecz mnie trapi. :) Kilka osób krytykuje gościa za to, że jego serwisy zwracają ViewModele i zaleca użycie AutoMappera, a on w pewnym miejscu przyznaje im zresztą rację. Domyślam się, że mapowanie miałoby się odbywać w kontrolerze - wnioskuję z tego, że tak to jest zrobione w większości przykładów użycia AutoMappera jakie znalazłem w sieci. Intuicja mówi mi jednak, że nie jest to koniecznie to czego bym chciał. ;)

Gdzieś na Stack Overflow natrafiłem jednak na taką opinię, która wydaje mi się sensowna:

View models are intended to provide information to and from views and should be specific to the application, as opposed to the general domain. Controllers should orchestrate interaction with repositories, services (I am making some assumptions of the definition of service here), etc and handle building and validating view models, and also contain the logic of determining views to render.
By leaking view models into a "service" layer, you are blurring your layers and now have possible application and presentation specific mixed in with what should focused with domain-level responsibilities.

Czy to rzeczywiście nie jest trochę rozmywanie warstw?

MMSz napisał(a):

Domyślam się, że mapowanie miałoby się odbywać w kontrolerze - wnioskuję z tego, że tak to jest zrobione w większości przykładów użycia AutoMappera jakie znalazłem w sieci.

Mapowanie w kontrolerze? Ale czego na co?
Generalnie w przykładach w sieci, cała logika aplikacji odbywa się w kontrolerach. Tylko to nie jest dobre, a nawet jest bardzo złe.

Controllers should orchestrate interaction with repositories, services (I am making some assumptions of the definition of service here), etc and handle building and validating view models, and also contain the logic of determining views to render.

Nieprawda - kontrolery nie mają niczego organizować, a już zwłaszcza robić niczego związanego z repozytoriami.

By leaking view models into a "service" layer, you are blurring your layers and now have possible application and presentation specific mixed in with what should focused with domain-level responsibilities.

No niby tak. Zawsze można klasy zwracane z serwisów aplikacyjnych uznać za zwykłe DTO i "przemapować" je sobie na ViewModele (niekoniecznie klonując kod, można po prostu podziedziczyć, albo dodać klasy metadanych prezentacji) w warstwie GUI.