wkurza mnie to że w Polsce tak mało popularny jest jeszcze ASP.NET MVC

Marzyłem o pracy w ASP.NET MVC, którego znam od kołyski - od wersji beta :) Zapoznawałem się i pogłębiałem wiedzę o każdej kolejnej wersji, patrzyłem jak ta technologia dynamicznie się rozwija, jak na Zachodzie gromadzi się wokół niej coraz większa społeczność, nawet jak sam Microsoft go promuje na maxa kosztem WebFormsów, byłem przez pewien czas podobno jedynym posiadaczem strony w ASP.NET MVC na pewnym polskim hostingu. Niestety musiałem podjąć pracę w technologii nie związanej z firmą Microsoft ponieważ udział w 3 rozmowach kwalifikacyjnych w Warszawie uświadomił mi, że wciąż w Polsce dominuje ASP.NET WebForms, które są dla mnie nie do zaakceptowania i jest to dla mnie nienaturalny sposób tworzenia aplikacji. Chciałem się pożalić. :(

Spoko tu zawsze wszystko dochodzi z lagiem ;) (aczkolwiek nie znam się na .net i nie mogę stwierdzić, że taki jest powód opisanej sytuacji ).

Jeśli większa firma ma już jakieś swoje systemy w WebFormsach, to nie przepisze ich nagle na MVC, woli utrzymywać.
Ogłoszenia z wymaganą znajomością MVC się zdarzają, więc to nie jest tak, że nie ma w ogóle. No i zawsze można wybrać moją drogę - freelancing.
Z drugiej strony, jak się dobrze w WebFormsach namota, to i prawie MVC z tego wyjdzie. ;)

A podobno, to teraz do Javy wypuścili coś takiego jak WebFormsy i teraz javowcy się podniecają czymś, co było w .NET od wielu lat. (I było ujowe.)

A podobno, to teraz do Javy wypuścili coś takiego jak WebFormsy i teraz javowcy się podniecają czymś, co było w .NET od wielu lat. (I było ujowe.)

Nie wiem co masz na myśli i czym ty się podniecasz, nie wiem też co to są WebFormsy, ale moim zdaniem wzorzec MVC to dość słaby pomysł i ja jestem zwolennikiem frameworków komponentowych.

Co jest takiego w tym asp.cośtam, żeby programista Javy miał się tym zainteresować?

Wibowit napisał(a):

Nie wiem co masz na myśli i czym ty się podniecasz, nie wiem też co to są WebFormsy, ale moim zdaniem wzorzec MVC to dość słaby pomysł i ja jestem zwolennikiem frameworków komponentowych.

Co jest takiego w tym asp.cośtam, żeby programista Javy miał się tym zainteresować?

Widzę, że u Javowców nawala nie tylko pisanie, ale i czytanie ze zrozumieniem.
Nie Javowcy mają się podniecać WebFormsami, ale ponoć nowością dla nich jest podejście oparte na komponentowo-klikaczowym tworzeniu stron z gotowych kontrolek i trzymaniu wszystkiego co się da we viewstate (sesji i hibernatowego cache również). Nie wiem, czy to się czasem JSF nie nazywa.

A co złego w MVC? Testowalność, porządek i sensowny markup?

Czy w desktopowym GUI też używasz MVC i dlaczego?

Co jest modelem, widokiem i kontrolerem w MVC? Widok to pewnie HTML, model to encje np Hibernata, a kontroler to zapewne cała reszta.

Framework komponentowy o który mi chodziło to Apache Wicket. Spis tagów Wicketa: https://cwiki.apache.org/WICKET/wickets-xhtml-tags.html Jak widać nie jest ich dużo i każdy w miarę ogarnięty projektant stron powinien sobie z nimi poradzić - spory plus szablonów Wicketa to to, że designer może modyfikować szablony bez problemu w dowolnym etapie tworzenia aplikacji i ewentualne poprawki w hierarchii tagów wicketowych będą co najwyżej kosmetyczne.
Wicket jest komponentowy, a więc można np dziedziczyć po komponentach nadrzędnych (włączając w to dziedziczenie skojarzonego HTMLa).
Dzięki ułożeniu w komponenty mamy praktycznie za darmo AJAXa jak i w ogóle łatwe podmienianie komponentów na stronie.

Jedni wolą zabawę w kontrolery (MVC jest w Javie od milionów lat), a inni tak jak ja wolą komponenty. Komponentowe frameworki na pewno są cięższe do opanowania dla początkujących, ale wysiłek się opłaci.

Jak dla mnie główna różnica między klasycznym MVC, a komponentowymi jest taka, że komponentowe to w zasadzie MVC tyle, że kontroler jest osobny dla każdego komponentu. Czyli komponentowe jest po prostu bardziej obiektowe.

Wibowit napisał(a):

Czy w desktopowym GUI też używasz MVC i dlaczego?

Nie, w desktopie używam MVP, zresztą podobnie jak w WebFormsach.
Tylko nie wiem co to ma do rzeczy, w aplikacji desktopowej mogę trzymać graf obiektów w pamięci przez cały czas jej działania, w webowej nie.

Co jest modelem, widokiem i kontrolerem w MVC? Widok to pewnie HTML, model to encje np Hibernata, a kontroler to zapewne cała reszta.

To chyba w projekcie na zaliczenie na studiach albo w durnych tutorialach M$ dla Amerykanów. Podejście kontroler do wszystkiego jest zapewne naturalne dla programistów Cobola, ale nie dla normalnego programisty, który stara się mieć klasy poniżej 10 tysięcy linii kodu. ;)

Widok to HTML z drobnymi wstawkami C# pozwalającymi na jego dynamiczne generowanie, np. w ten sposób
Model to obiekty wyświetlane w widokach, czyli zawierające nie tylko pola danego formularza, ale też dane pomocnicze, takie jak np. lista elementów z jakiegoś słownika. Niektórzy (a może większość) nazywa to ViewModelem. U mnie klasy te nie mają nic wspólnego z bazą.
Kontrolery przechwytują akcje użytkownika, przekierowują między widokami i wywołują faktyczne metody z warstw niższych, które realizują właściwe operacje biznesowe, transformują obiekty ViewModeli do encji, walidują dane, przeprowadzają obliczenia, zapisują dane do bazy, itd. Wg. niektórych konwencji to wszystko nazywa się właśnie Modelem.

MVC to wzorzec projektowy warstwy interfejsu użytkownika, a nie całej aplikacji. Niestety nie wszyscy to rozumieją i próbują upchać całą aplikację w jednej warstwie, co zazwyczaj kończy się tragicznie. W mały projekcie można tak zrobić, ale już przy średnim takie podejście kończy się źle.

Dzięki ułożeniu w komponenty mamy praktycznie za darmo AJAXa jak i w ogóle łatwe podmienianie komponentów na stronie.

Komponent w sensie reużywalną porcję HTMLa i związanego z nim kodu?
W ASP.NET MVC są do tego takie mechanizmy jak HtmlHelper, EditorTemplates oraz zwykłe współdzielone kawałki widoków.

Jedni wolą zabawę w kontrolery (MVC jest w Javie od milionów lat), a inni tak jak ja wolą komponenty.

I właśnie z myślą o programistach Visual Basic, którzy tak jak Ty wolą komponenty Microsoft stworzył ASP.NET WebForms. Przeciągasz komponenty z toolboxa, dodajesz im w paru kliknięciach obsługę zdarzeń i gotowe! Szkoda tylko, że działa jedynie pod IE i tylko w intranecie, bo przeciętna strona waży 2Mb. ;P

Jak dla mnie główna różnica między klasycznym MVC, a komponentowymi jest taka, że komponentowe to w zasadzie MVC tyle, że kontroler jest osobny dla każdego komponentu. Czyli komponentowe jest po prostu bardziej obiektowe.

No tak, mamy więcej obiektów, to jesteśmy bardziej obiektowi. Merkury merkury = new Merkury(new Merkury().nazwaMerkurego)... no po prostu dużo obiektów. ;P

Widok to HTML z drobnymi wstawkami C# pozwalającymi na jego dynamiczne generowanie, np. w ten sposób

Fory, ify i inne gówna w HTMLu? A idź pan z czymś takim. HTML, moim zdaniem, powienien być wolny od czegoś takiego. Te wstawki to jak cofanie się do PHP czy JSP. Mieszanie logiki z widokiem. Jak niby projektant strony ma później edytować taki szablon ze wstawkami kodu?

Nie, w desktopie używam MVP, zresztą podobnie jak w WebFormsach.
Tylko nie wiem co to ma do rzeczy, w aplikacji desktopowej mogę trzymać graf obiektów w pamięci przez cały czas jej działania, w webowej nie.

Czemu w webowej nie? Wicket serializuje komponenty do sesji i wszystko dobrze lata. Oczywiście można sterować tym mechanizmem, aby sesja nie "wybuchła" - np nie trzymać w zserializowanej sesji modeli, których zawartość można wyciągnąć z bazy. Somekind pewnie wszystko ładował do sesji i miał problem, ale to jest wyłącznie jego problem.

I właśnie z myślą o programistach Visual Basic, którzy tak jak Ty wolą komponenty Microsoft stworzył ASP.NET WebForms. Przeciągasz komponenty z toolboxa, dodajesz im w paru kliknięciach obsługę zdarzeń i gotowe! Szkoda tylko, że działa jedynie pod IE i tylko w intranecie, bo przeciętna strona waży 2Mb. ;P

W Javowym GWT przeciąga się elementy z toolbara i wychodzi np GMail. W czym przeszkadza przeciąganie elementów z toolbara? To że jakieś tam WebFormsy są skopane, to mnie nie zaskakuje, ale żeby twierdzić, że wszystkie frameworki komponentowe (niezależnie od języka) są od tego czegoś gorsze to po prostu ignorancja.
Apache Wicket jest komponentowy w 100 %, a nie polega na przeciąganiu komponentów z toolbara - nie wiem nawet czy są takie narzędzia do Wicketa, bo takie podejście w Wickecie jest dość nienaturalne; zresztą widoki robią projektanci HTMLa, programista Javy tylko i wyłącznie sprawdza hierarchię komponentów i ją odpowiednio mapuje.

Kontrolery przechwytują akcje użytkownika, przekierowują między widokami i wywołują faktyczne metody z warstw niższych, które realizują właściwe operacje biznesowe, transformują obiekty ViewModeli do encji, walidują dane, przeprowadzają obliczenia, zapisują dane do bazy, itd. Wg. niektórych konwencji to wszystko nazywa się właśnie Modelem.

Podział logiki i dostępu do danych na warstwy da się zrobić w każdym podejściu. W komponentowych każdy komponent ma własną logikę. W komponentowych komponenty oprócz własnej logiki mają też własne szablony HTML, CSSy i JSy.

Podsumowując:
Nie widzę niczego świetnego w ASP.NET MVC, ani nawet w samym podejściu MVC. Frameworków MVC jest setki, komponentowych też jest mnóstwo i jeśli przyrównujesz coś do Javy, czy Rubiego, Pythona, Scali czy czegokolwiek, to napisz dokładnie do czego, bo w każdym z tych języków jest mnóstwo napisanych frameworków w różnych podejściach. Podobno nawet w PHP są frameworki komponentowe.

Wibowit napisał(a):

Fory, ify i inne gówna w HTMLu? A idź pan z czymś takim. HTML, moim zdaniem, powienien być wolny od czegoś takiego. Te wstawki to jak cofanie się do PHP czy JSP. Mieszanie logiki z widokiem.

No bez przesady, to są proste operacje typu wylistowanie elementów jakiejś kolekcji w pętli albo wyświetlenie komunikatu, jeśli lista jest pusta. Całość tej "logiki" jest powiązana z widokiem. Dzięki takiemu szablonowi od razu widać jak strona będzie wyglądała. No i wszystko jest zgodnie z wzorcem, Widok odpowiada za prezentację danych.
Jedynym znanym mi alternatywnym podejściem jest generowanie gotowego HTML z poziomu kodu, co jest dopiero syfiaste.

Jak niby projektant strony ma później edytować taki szablon ze wstawkami kodu?

A to projektant jest taki głupi, że nie wie co to znaczy if i for? Nieźle. Ale nawet jeśli, to zawsze można mu powiedzieć, że jak coś się zaczyna od małpy, to ma nie ruszać.
Zresztą, dlaczego projektant strony ma coś edytować później? Najpierw się robi layout, potem go wypełnia treścią.

Czemu w webowej nie?

Jeśli nie wiesz, czemu w aplikacji webowej nie mogę trzymać obiektów w pamięci u klienta, to nie wiem, czy w ogóle powinieneś się tu wypowiadać...

Somekind pewnie wszystko ładował do sesji i miał problem, ale to jest wyłącznie jego problem.

Nie widziałeś nigdy mojego kodu, a się wypowiadasz. Ja w sesji trzymam wyłącznie dane związane z uwierzytelnianiem i autoryzacją. Ale ok, pewno można tam wrzucać całe drzewa obiektów i twierdzić, że wszystko jest w porządku. :D

To że jakieś tam WebFormsy są skopane, to mnie nie zaskakuje, ale żeby twierdzić, że wszystkie frameworki komponentowe (niezależnie od języka) są od tego czegoś gorsze to po prostu ignorancja.

Ale przeczytałeś w ogóle ten cytat, który zacytowałeś? Przecież ja w nim śmieję się z ASP.NET WebForms, nie z Javiy ani innych języków.

W komponentowych komponenty oprócz własnej logiki mają też własne szablony HTML, CSSy i JSy.

Kwestia tego co tak naprawdę w danej technologii definiuje się jako "komponent". Być może podejście to jest świetne i cudowne, nie wiem, bo nie znam.
Najważniejszy i tak jest rezultat, w przypadku technologii webowej jest nim wyjściowy kod, który wyświetla przeglądarka. Zazwyczaj jest tak, że im więcej magii w technologii, tym więcej zbędnych danych przesłanych do klienta.

Nie widzę niczego świetnego w ASP.NET MVC,

Nic dziwnego, że nie widzisz, skoro nie jesteś webowym programistą .NET. :)
W .NET do tej pory było praktycznie tylko albo "wygodne" i "szybkie" programowanie komponentowo-zdarzeniowe w WebFormsach, które wiązało się z trudnościami w testowaniu i debugowaniu. ASP.NET MVC jest w tym sensie rewolucją - szybkie, testowalne, debugowalne, proste i dające pełnię władzy nad generowanym HTMLem.

Frameworków MVC jest setki, komponentowych też jest mnóstwo i jeśli przyrównujesz coś do Javy, czy Rubiego, Pythona, Scali czy czegokolwiek, to napisz dokładnie do czego, bo w każdym z tych języków jest mnóstwo napisanych frameworków w różnych podejściach.

Ależ napisałem, dzisiaj o 1:20, że w tamtej wypowiedzi chodziło o JSF.

Spoko, znasz tylko jedyne słuszne frameworki od MS oraz gównianego JSF (a może i jego nie znasz) i na tej postawie robisz wielkie porównanie. 100% profesjonalizm.

No tak, mamy więcej obiektów, to jesteśmy bardziej obiektowi. Merkury merkury = new Merkury(new Merkury().nazwaMerkurego)... no po prostu dużo obiektów. ;P

Tak piszą siszarpowcy ;p

Podejście komponentowe jest też we Flexie. Bardzo dobrze się w tym pisze :)

Flex to inna bajka.
MVC świetnie sprawdza się przy tworzeniu stron internetowych, budowanie stron w WebFormsach to nieporozumienie, bo powoduje okropny bajzel w kodzie.

U mnie wszystkie nowe projekty - tylko i wyłącznie ASP.NET MVC 3 :)

emfasi a Ty własną firmę masz czy jak?

Nie mogę przebrnąć przez wasze długie posty Wibowit i somekind,
w związku z czym pytanie do Wibowita: Javowcy rezygnują z MVC?

1. MVC zajmuje mniej kodu i pozwala rozdzielić pracę designera i klepacza.
2. Strony oparte o WebFormsy (czyli komponenty) tworzy się szybciej, ale są zawikłane przez niestosowanie modelu
3. Webformsy korzystają z nienaturalnych rozwiązań jak np. utrzymywanie sesji mimo że http jest bezpołączeniowy,
   ogólnie według mnie to jedna wielka pomyłka, wszystko co dzieje się na stronie powinno być wykonywane za pomocą JS'a a nie jakiegoś ViewState'a. To takie zmienianie html'a na siłę.

wiewiorek napisał(a):

emfasi a Ty własną firmę masz czy jak?

Nie, pracuję jako programista.

1. MVC zajmuje mniej kodu i pozwala rozdzielić pracę designera i klepacza.

Zależy na co spojrzeć. Razor pozwala na ify, pętle i w ogóle chyba jakiekolwiek kod umieszczać pomiędzy HTMLem. A czysto komponentowy framework Apache Wicket nie pozwala w ogóle na żadne instrukcje sterujące, ani kod w jakimkolwiek języku w szablonach HTML. Lista tagów Wicketowych: https://cwiki.apache.org/WICKET/wickets-xhtml-tags.html

2. Strony oparte o WebFormsy (czyli komponenty) tworzy się szybciej, ale są zawikłane przez niestosowanie modelu

W Apache Wicket komponent dzieli się na: model, kontroler + mapowanie widoku w Javie oraz szablon HTML. Dodatkowo komponent ma dzieci i te dzieci inicjalizuje jakimś tam modelem (względnie model jest wstrzykiwany).

3. Webformsy korzystają z nienaturalnych rozwiązań jak np. utrzymywanie sesji mimo że http jest bezpołączeniowy,

HTTP jest bezstanowy, a nie bezpołączeniowy.

Sesje nienaturalne? A jeśli masz formularz na kilka ekranów i chcesz obsługiwać klikanie przycisku wstecz w przeglądarce? Musisz wtedy mieć jakiś stan w sesji.

Pisząc w komponentowym frameworku Apache Wicket można w ogóle nie korzystać z sesji, sesje są automatycznie tworzone właśnie wtedy, kiedy są potrzebne. Można też zrobić interfejs RESTowy. Do wyboru do koloru. I można oczywiście zoptymalizować zajętość sesji, na pewno podstawą w Wickecie jest korzystanie z odłączanych modeli (LoadableDetachableModel i pokrewne).

Wicket 6 ma być oparty na jQuery (tzn przede wszystkim jego AJAXowe funkcje) i wtedy będzie można dowolnie decydować co zrobić za pomocą jQuery, a co za pomocą mechanizmów Wicketa. Na chwilę obecną wykorzystanie jQuery w Wickecie 1.5 i niższych sprawia chyba czasem nieco problemu.

MVC kojarzy mi się z takim schematem:

1. Leci sobie żądanie do serwera.
2. Serwer rozgląda się za odpowiednim kontrolerem.
3. Ten kontroler jest wielgachny i zajmuje się wyciągnięciem wszystkich potrzebnych modeli dla danego żądania i wciśnięciem je do widoku.
4. Widok zajmuje się generowaniem HTMLa dla użytkownika.

W komponentowych jest podobnie, z tym, że zamiast jednego wielkiego kontrolera dla każdego żądania, odpowiedni komponent główny deleguje pracę do komponentów-dzieci, które mają własną logikę do przerabiania danych i mogą istnieć samodzielnie, można je wrzucić jako dziecko do innego komponentu (głównego lub nie). Komponent główny w Wickecie to ZTCP klasa Page. Oczywiście można mieć hierarchie komponentów i delegowanie może sobie lecieć stopniowo wgłąb, tak samo jak to jest w obiektowych językach programowania.

Komponenty w Wickecie obsługują dziedziczenie, zarówno szablonów jak i logiki.

Wicket nie należy do najszybszych frameworków webowych (z drugiej strony nie jest też źle), no ale coś trzeba wybrać - albo ceni się czas programisty, albo czas procesora.

Javowcy rezygnują z MVC?

Po raz N-ty powtarzam: Javowcy z niczego nie rezygnują. Do Javy jest sporo popularnych i wspieranych frameworków MVC. Tak samo z frameworkami komponentowymi.

Wicket pozwala patrzeć na stronę, żądanie, sesję, mapowanie urli słowem wszystko co sobie wymyślicie - jak na normalny obiekt, wszystko co jest na stronie jest obiektem który ma swój cykl życia (komponenty), w przypadku MVC mamy kontroler który wybiera obiekty i wpycha je do widoku który jest hmm no właśnie, wszystkim, może mieć dowolną ilość logiki, może nie mieć jej wcale, ale obiektem to raczej to ciężko nazwać - no raczej te ify na stronie cyklu życia nie mają.
Z drugiej strony, jeśli miałbym pisać zwykłą stronkę z kilkoma widokami - zdecydowanie lepszy jest MVC - lżejszy, brak spasionych sesji, łatwiej utrzymać bezstanowy charakter stron.
W przypadku złożonych aplikacji, gdzie są mega wielkie wizardy komponenty masakrycznie upraszczają życie w porównaniu z MVC. Nie ma jakichś dziwnych definicji routingu, przekierowań, generowania adresów dla poszczególnych stron/kroków.
W przypadku AJAXA trzeba pisać akcję w kontrolerze, i znowu definiować widok (np widok częściowy w RoR) - troche dużo tej pracy, a jak takich żądań dużo - to reuse kodu to odwoływanie się z jednego widoku do innego kontrolera, albo sztuczne metody w kontrolerach, albo inne Helpery (w RoR 2.x było to często generowanie kodu html w kodzie rubiego...a tfe!), po prostu jest tego troche, w Wickecie jest to raptem kilka lini kodu...w Javie, a więc nawet ciężko się pomylić bo IDE pomaga, i nie muszę nic w żadnych pseudo skrypto językach pisać - oczywiście kosztem pamięci w sesji serwera.
Co do modeli to i tak Wicket jest tylko technologią widoku, odwołuje się np. do ServiceLayer który opakowuje jakiś inny DomainModel więc z punktu widzenia Wicketa mi zwisa inna warstwa Ja to tylko prezentuje bądź zbieram dane przekazując to innej warstwie - z tym że strona nie musi być sztywno zależna od modelu co daje więcej wolności w porównaniu ze standardowym MVC.

a i co do testowania. Jako że każdy komponent ma swój cykl życi - mogę sobie spokojnie testować całe strony, bądź pojedyncze komponenty - każdy z osobna. A że każdy komponent wicketa jest zażądzany przez framework mogę do niego wstrzykiwać co mi się podoba - czyli w przypadku testowania mogę mokować co mi się tylko podoba i raczej łatwiej testować taki javowy kod niż rozgałęzienia w pseudo skrypto języku (nie ważne czy to MVC javowe, msowe, rorowe czy jakiekolwiek inne).
a i jeszcze jedno odnośnie testów - jako że komponenty wicketa to kod w javie - w trkacie testowania mogę spokojnie korzystać ze wszystkich dobrodziejstw sprawdzania jakości kodu - kobertury, czekstajle itd itp, w taki sam sposób jak resztę kodu w aplikacji co jest dość wygodne :)

a, i jak już mówimy o komponentowych frameworkach to warto wspomnieć o Vadinie, tam już nawet żadnego htmla nie ma, po prostu java.

A jak testujecie tego Wicketa, bo widze ze taki testowalny jest. Ja dopiero w sumie zaczynam, i w jednym projekcie costam klepie troche w aplikacji ktora ma juz sporo kodu, i mam problemu z testowaniem tego. Np. uzywamy Springa, czyli mamy pola z anotacjami @SpringBean - ale ona jjest tylko dla pol, wiec ni uja nie moge tego zamockowac. Jak testujecie ModalWindow i popupy? WicketTester tez do konca sie nie spisuje.
Powaznie pytam bo chce sie nauczyc, bez jakichs docinek prosze.

Nie no się wkurzyłem - 3 tygodnie temu byłem na rozmowie rekrutacyjnej w jednej jedynej firmie jaką znalazłem w Warszawie tworzącej strony w ASP.NET MVC i nie doczekawszy się od nich odpowiedzi napisałem do nich pytanie co było głównym powodem jak mniemam odrzucenia mojej kandydatury - ciekawe czy odpiszą. :P :D

Nie odpiszą.

Odpisali jakimś standardowym tekstem, że 'nie są w stanie na ten moment zaproponować mi stanowiska zgodnego z moimi oczekiwaniami' - lol. :D

Tak w ogóle to podczas rekrutacji w tej firmie realizującej projekty w ASP.NET MVC była pani z HR i pan z IT. Padły tylko dwa pytania techniczne: pierwsze w stylu gdzie w aplikacji ASP.NET MVC nawiązuje połączenie z bazą danych to odpowiedziałem, że w connectionStringu - mniemam, że o to chodziło, bo nie usłyszałem żadnych zastrzeżeń, drugie pytanie było w stylu jak mógłbym zrealizować logowanie błędów, to na początku stwierdziłem, że przy użyciu Elmah - ale tu dostałem sygnał, że o co innego chodziło więc stwierdziłem, że użyłbym własnego kontrolera błędów i tam w akcjach przechwytywał błędy w stylu 500 i np. zapisywał do bazy - pan z IT się troszkę zastanowił i powiedział coś w stylu aha ok. A może im się nie spodobało to, że powiedziałem, że nie znam Web Formsów (chociaż o to nie pytali, ale to chyba nie jest wada, bo sami powiedzieli, że realizują projekty w ASP.NET MVC) lub kwota 2500 zł netto jaką zaproponowałem okazała się za wysoka. :P

Komercyjne mam tylko w PHP - 2 lata, w ASP.NET MVC komercyjnego 0, ale to nie znaczy, że go nie znam - realizowałem w nim pracę inżynierską i obecnie magisterską. Ta firma jest w Warszawie i jest to http://www.qualent.pl/ - sami na rozmowie mówili, że realizują kilka projektów od ASP.NET MVC 1 do ASP.NET MVC 4 - w sumie trochę mnie to nawet zaskoczyło, zwłaszcza że ASP.NET MVC 4 jest jeszcze w fazie beta więc realizowanie dla klienta aplikacji w wersji, która może mieć jeszcze sporo błędów jest trochę dziwne. Rozmowa z nimi miała miejsce 3 czy 4 tygodnie temu.

Jeszcze nie jestem obroniony.

A tak na marginesie to mogę tylko dodać, że z mego punktu widzenia to wystarczyło dobrze poznać framework MVC Symfony (PHP) i zaznajomienie z ASP.NET MVC było bardzo proste - wykorzystanie przez obie technologie wzorca MVC sprawia, że nauka nowej technologii wykorzystującej MVC jest bajecznie prosta, a różnice minimalne.

Powiedziałbym, że różnice pomiędzy MVC w PHP i MVC w C# jednak będą większe. Ogólny zarys działania może taki sam, ale reszta (cały Framework, runtime .NET, biblioteki) jest zupełnie inna.

Ciekawe tylko czy oni korzystają z dobrodziejstw MVC 4 czy tylko zmienili numerek przy wersji frameworka ;-) Bo główne zmiany jakie weszły w MVC 4 to wszelkiej maści wsparcie dla asynchroniczności, a tak poza tym to zbyt wiele różnic nie ma między MVC 3 a 4.