Panie, nowe idzie! Czyli pierwsze spojrzenie na ASP.NET vNext
Dzisiaj dowiedziałem się, że Microsoft przy okazji upublicznienia testowej wersji 14 już odsłony swojego flagowego IDE czyli Visual Studio przygotował również kolejną wersję webowego frameworka: ASP.NET. Uznałem więc, że jest to dobra okazja aby już teraz przyjrzeć mu się bliżej.
Programującym aplikacje webowe nie trzeba przedstawiać frameworka ASP.NET, a dla pozostałych dwa zdania o nim. ASP.NET jest biblioteką stworzoną przez firmę Microsoft jednak udostępnioną jako open-source, umożliwiającą pisanie aplikacji webowych w środowisku .NET. Można powiedzieć, że jest to bezpośredni konkurent javowych rozwiązań i jest mniej więcej tak samo popularny jak one.
Ponieważ aktualnie wydanie 14 Visual Studio jest w wersji mocno testowej i nawet sam producent nie poleca jego instalacji poza maszyną wirtualną to informacje i swoje spostrzeżenia oprę na udostępnionych m.in. na stronie www.asp.net materiałach. Nie będzie to tutorial jak programować przy użyciu nowego narzędzia, a jedynie krótki przegląd tego co zostało zmienione.
Pierwsza informacja jaką można znaleźć jest taka, że framework został stworzony całkowicie od podstaw. Takie podejście ma na pewno jedną zaletę – brak naleciałości i nieudanych rozwiązań z poprzednich wersji. Jednak ma też wady, np. to, że całkowicie świeży kod na początku może nie być wystarczająco dobrze przetestowany i dlatego jestem pewien, że pierwsze „komercyjne” wydanie tej biblioteki nie będzie jeszcze tym, które developerzy będą rzucać na produkcję, jednak myślę, że po kilku łatkach na pewno będzie można ASP.NET vNext uznać za gotowy produkt. ASP.NET vNext połączy MVC, Web API o Web Pages w jeden framework. Brakuje informacji o Web Forms dlatego mogę przypuszczać, że Microsoft zdecydował się porzucić tą technologię.
Kolejna informacja jest taka, że w końcu zdecydowano się umieścić wstrzykiwanie zależności bezpośrednio we frameworku. Każdy kto poznał zalety tej techniki budowania aplikacji doceni takie posunięcie. Ale jak to konkretnie będzie działać i na ile wygodne się okaże zobaczymy.
Z udostępnionych materiałów możemy się też dowiedzieć, że Microsoft zdecydował się mocno postawić na wydajność i przystosowanie do tworzenia aplikacji pracujących w chmurze. O ile chmurowymi rozwiązaniami się jeszcze nie zajmowałem o tyle ogólny boost do szybkości działania bardzo cieszy. Cieszy też informacja, że od tej pory aplikacje pisane w ASP.NET nie będą musiały być uruchamiane za pośrednictwem serwera IIS (ale oczywiście taka możliwość będzie), ale też będą mogły działać jako normalne, niezależne procesy. Być może to wszystko poprawi trochę sytuację na rynku tanich hostingów, bo przy takim samym, często marnym, sprzęcie jest szansa na uzyskanie lepiej działającej aplikacji, albo obniżenie cen poprzez zwiększenie ilości uruchomionych na jednej maszynie witryn.
Zdarzyło Ci się, że twoja strona przestała działać, albo działała nie tak jak powinna po tym jak firma hostingowa zaktualizowała biblioteki dostępne na serwerze? Jeśli tak, to tym bardziej polubisz ASP.NET vNext. Od teraz każda aplikacja będzie posiadała własną wersję frameworka mimo, że wszystkie będą pracowały na jednym serwerze. Tak więc jeśli okaże, się, że jedna z Twoich aplikacji wymaga do pracy starszej wersji bibliotek to nie będzie to oznaczało konieczności rezygnacji z dobrodziejstw najaktualniejszych wydać frameworka w pozostałych programach pracujących na tej samej maszynie.
Teraz coś, czego brakuje mi zawsze kiedy naprawiam jakieś błędy w aplikacji – nowa wersja ASP.NET będzie korzystała z kompilatora Roslyn do dynamicznego kompilowania kodu. Tak tak, od teraz program będzie budowany na bieżąco. Poprawienie jednej linijki w kontrolerze oznacza zawsze konieczność zatrzymania aplikacji, dodania zmian, i ponownego czekania na uruchomienie serwera co przy większych projektach trwa kilkanaście sekund, ale wykonywane często opóźnia pracę. Nawet jeśli ta dynamiczna kompilacja będzie wymagała mocnego sprzętu to uważam, że jest tego warta. Dodatkowo przeczytać można, że to rozwiązanie pozwoli na edycję programu będącego już na serwerze – wyobraź sobie to, możesz poprawiać drobne błędy w aplikacji klienta bez konieczności przechodzenia przez całą ścieżkę ponownego uploadu na serwer i uruchamiania, edytujesz kod i od razu wszystko działa (no chyba, że złe zmiany wprowadziłeś)! Co prawda edycja bezpośrednio na serwerze dostępna będzie prawdopodobnie tylko dla aplikacji pisanych dla Windows Azure jednak jest to duży krok w stronę skrócenia czasu potrzebnego na naprawę błędów w kodzie produkcyjnym.
Z rzeczy bardziej związanych już z samym tworzeniem projektu to zmienia się sposób jego konfiguracji. Do tej pory większość ogólnoprojektowych ustawień znajdowało się w pliku Web.config. Teraz zadanie to częściowo przejmie plik project.json, tak, dokładnie Microsoft przerzucił się z opartej na XMLu struktury na lżejszy format JSON. Czyżby ktoś w firmie stwierdził, że XMLa zostawiamy Javie, która jak wiadomo go uwielbia? :D W każdym razie teraz plik project.json można porównać do pliku POM.xml wykorzystywanego przez javowego Mavena. Znajdują się w nim wszystkie zależności wymagane przez projekt, które w razie konieczności są automatycznie pobierane przez manager pakietów NuGet. Oprócz tego jest w nim opisana konfiguracja wymagana do budowy aplikacji i komendy ułatwiające uruchamianie jej z poziomu linii komend. Poza plikiem project.json podczas korzystania z szablonu aplikacji dodawany jest też plik config.json, w którym znajdują się ustawienia projektu takie jak connection string dla połączenia z bazą danych.
Jeśli chodzi o zmianę sposobu konfiguracji projektu to tutaj mam raczej neutralne nastawienie. Nie widzę przeważających wad lub zalet, wszystko okaże się kiedy będę miał okazję przetestować nową bibliotekę.
Skoro tyle się zmieniło to nasuwa się pytanie czy wiedza o starszych wersjach w ogóle do czegoś się przyda? Owszem, przyda się, a nawet nie będzie wymagana zbytnia jej zmiana ponieważ po skonfigurowaniu projektu, co będzie procesem nieco innym niż wcześniej, samo dodawanie kontrolerów i widoków wygląda tak samo jak w MVC3, 4 czy 5. Co prawda w tym momencie nie ma gotowego narzędzia do bardziej automatycznej obsługi zależności i trzeba je uzupełniać ręcznie w pliku project.json, jednak jest bardzo prawdopodobne, że Microsoft doda coś ciekawego do kolejnej wersji Visual Studio kiedy pojawi się ono w gotowej formie.
Na koniec jeszcze jedna ważna informacja, ASP.NET vNext jako projekt open-source nie będzie wymagał do pracy Visual Studio, zapewne inne popularne edytory dostaną pluginy do jego obsługi, dodatkowo biblioteka będzie obsługiwana przez Mono! Jeśli będzie to działało wystarczająco dobrze, to być może będzie możliwość uruchamiania aplikacji pisanych w ASP.NET vNext na linuxowych serwerach.
Podsumowując, uważam, że Microsoft dobrze zrobił odświeżając framework nie bojąc się nawet odciąć go trochę od poprzednich wydań. Jednak zastanawia mnie to delikatne odejście od zasady „konwencja nad konfiguracją”, bo, jak każdy programujący w tej technologii wie, w poprzednich wersjach ASP.NET dzięki odpowiednim nazwom i strukturom plików i katalogów można było całkowicie pominąć konieczność konfiguracji takich rzeczy jak odpowiednie ścieżki do kontrolerów czy widoków. I to moim zdaniem działało bardzo przyjemnie i pozwalało się skupić na konkretnej funkcjonalności. Teraz ich rozwiązanie zaczyna bardziej przypominać to co jest w webowej Javie.
Ogólnie wrażenie jest z mojej strony raczej dobre, jednak z oceną niektórych elementów wstrzymam się do czasu wydania jakiejś stabilnej wersji nowego Visual Studio i samego frameworka. Na razie pozostaje czekać i pracować na ASP.NET MVC4 i 5 :)
Zieeeew, w RoR mamy to wszystko od dawna :D
Co do wydajności i możliwości konfiguracji nowych wersji, to wszystko wygląda pięknie. Tylko na TANIE hostingi z asp.net nie ma najmniejszych szans. Raz że webserwisy (głównie gotowe webaplikacje) są okrutnie pazerne na pamięć. Więc na hostingach współdzielonych, które rzadko kiedy przydzielają więcej niż 128MB (pod PHP) w przypadku .net to za mało.
Można od razu łakomić się na VPS, ale koszty licencji oprogramowania wyrywają z butów. Choć hostingi webserwer.pl czy webio.pƖ mają całkiem dobre usługi współdzielone, to nie przebiją możliwości chmur typu azure.
Z kolei jest też sporo osób chronicznie uczulonych na „usługi cloud” ;)
To kwestia dogadania się, automat wszystkiego nie obsłuży od ręki.
Triss: tylko wciąż daleko wam z tym RoRem do wydajności asp.net pod IIS w obecnych, stabilnych wersjach ;}