Czy ktoś obok mnie po prostu NIE otrzymuje ASP.NET MVC? [Zamknięte]

Bawię się ASP.NET MVC od czasu CTP i podoba mi się wiele rzeczy, które zrobili, ale są rzeczy, których po prostu nie rozumiem.

Na przykład pobrałem wersję beta1 i tworzę z nią małą osobistą witrynę / życiorys / blog. Oto fragment z widoku ViewSinglePost:

 <%
        // Display the "Next and Previous" links
        if (ViewData.Model.PreviousPost != null || ViewData.Model.NextPost != null)
        {
            %> <div> <%

            if (ViewData.Model.PreviousPost != null)
            {
                %> <span style="float: left;"> <%
                    Response.Write(Html.ActionLink("<< " + ViewData.Model.PreviousPost.Subject, "view", new { id = ViewData.Model.PreviousPost.Id }));
                %> </span> <%
            }

            if (ViewData.Model.NextPost != null)
            {
                %> <span style="float: right;"> <%
                    Response.Write(Html.ActionLink(ViewData.Model.NextPost.Subject + " >>", "view", new { id = ViewData.Model.NextPost.Id }));
                %> </span> <%
            }
            %>
                   <div style="clear: both;" />
               </div> <%
        }
    %>

Obrzydliwy! (Zauważ również, że HTML jest tymczasowy zastępczy HTML, zrobię rzeczywisty projekt, gdy funkcjonalność będzie działać) .

czy robię coś źle? Ponieważ spędziłem wiele mrocznych dni w klasycznym ASP, a ta zupa z tagów bardzo mi o tym przypomina.

Wszyscy głoszą, jak można tworzyć czystszy HTML. Zgadnij co? 1% wszystkich ludzi patrzy na wynikowy HTML. Nie obchodzi mnie, czy formularze internetowe zepsują moje wcięcia w renderowanym HTML-u, o ile mam kod, który jest łatwy w utrzymaniu ... To nie jest!

Więc przekonwertuj mnie, zagorzałego gościa od formularzy internetowych, dlaczego miałbym zrezygnować z ładnie uformowanych stron ASPX w tym celu?

Edycja: Pogrubiono linię „temp Html / css”, aby ludzie mogli o tym mówić.

W porównaniu do formularzy sieci Web, MVC jest jednocześnie podejściem niższego poziomu do generowania kodu HTML z większą kontrolą nad danymi wyjściowymi strony i podejściem wyższego poziomu, bardziej opartym na architekturze. Pozwól, że przechwycę formularze sieci Web i MVC i pokażę, dlaczego uważam, że porównanie faworyzuje formularze sieci Web w wielu sytuacjach - o ile nie wpadniesz w niektóre klasyczne pułapki formularzy sieci Web.

Formularze internetowe

W modelu formularzy sieci Web strony odpowiadają bezpośrednio żądaniom strony z przeglądarki. Tak więc, jeśli kierujesz użytkownika do listy książek, prawdopodobnie będziesz mieć stronę o nazwie „Booklist.aspx”, do której go skierujesz. Na tej stronie musisz podać wszystko, co jest potrzebne do wyświetlenia tej listy. Obejmuje to kod do pobierania danych, stosowania dowolnej logiki biznesowej i wyświetlania wyników. Jeśli na stronę wpływa logika architektury lub routingu, musisz również zakodować logikę architektoniczną na stronie. Tworzenie dobrych formularzy sieci Web zwykle obejmuje tworzenie zestawu klas pomocniczych w oddzielnej (testowalnej jednostkowo) bibliotece DLL. Te klasy będą obsługiwać logikę biznesową, dostęp do danych i decyzje dotyczące architektury / routingu.

MVC

MVC przyjmuje bardziej „architektoniczne” spojrzenie na tworzenie aplikacji internetowych: oferuje standardowe rusztowanie, na którym można budować. Udostępnia również narzędzia do automatycznego generowania klas modeli, widoków i kontrolerów w ramach ustalonej architektury. Na przykład, zarówno w Ruby on Rails (tylko „Rails” od teraz), jak i ASP.NET MVC zawsze zaczynasz od struktury katalogów, która odzwierciedla ich ogólny model architektury aplikacji internetowych. Aby dodać widok, model i kontroler, użyjesz polecenia takiego jak "Skrypt / wygeneruj szkielet Railsów {modelname}" (ASP.NET MVC oferuje podobne polecenia w IDE). W wynikowej klasie kontrolera będą metody („Działania”) dla Index (lista pokazów), Show, New oraz Edit and Destroy (przynajmniej w Railsach MVC jest podobne). Domyślnie te „

Układ katalogów i plików jest istotny w MVC. Na przykład w ASP.NET MVC metoda Index dla obiektu „Book” prawdopodobnie będzie miała tylko jedną linię: „Return View ();” Dzięki magii MVC spowoduje to wysłanie modelu książki na stronę „/View/Books/Index.aspx”, na której znajdziesz kod do wyświetlania książek. Podejście Railsów jest podobne, chociaż logika jest nieco bardziej wyraźna i mniej „magiczna”. Zobacz stronę w aplikacji MVC jest zwykle prostsze niż strona Web Forms, ponieważ nie trzeba martwić się jak najwięcej o routingu, logiki biznesowej lub przenoszenia danych.

Porównanie

Zalety MVC opierają się na czystym oddzieleniu problemów i czystszym, bardziej skoncentrowanym na HTML / CSS / AJAX / Javascript modelu tworzenia wyników. Zwiększa to testowalność, zapewnia bardziej ustandaryzowany projekt i otwiera drzwi do witryn internetowych typu „Web 2.0”.

Jednak są też pewne istotne wady.

Po pierwsze, chociaż łatwo jest uruchomić witrynę demonstracyjną, ogólny model architektoniczny wymaga znacznej nauki. Kiedy mówią „Konwencja w konfiguracji”, brzmi to dobrze - dopóki nie zdasz sobie sprawy, że musisz się nauczyć konwencji wartej przeczytania w książce. Co więcej, często jest to nieco irytujące, aby dowiedzieć się, co się dzieje, ponieważ są polegając na magii zamiast wyraźnych połączeń. Na przykład, że „Return View ();” wezwać powyżej? Dokładnie to samo wezwanie można znaleźć w innych akcjach, ale trafiają one w różne miejsca. Jeśli rozumiesz konwencję MVCwtedy wiesz, dlaczego tak się dzieje. Jednak z pewnością nie kwalifikuje się to jako przykład dobrego nazewnictwa lub łatwego do zrozumienia kodu, a nowym programistom jest znacznie trudniej przyswoić niż formularze internetowe (to nie jest tylko opinia: miałem letniego stażystę, który uczył się formularzy internetowych w zeszłym roku i MVC w tym roku, a różnice w produktywności były wyraźne - na korzyść Web Forms). Przy okazji, Railsy są trochę lepsze pod tym względem, chociaż Ruby on Rails oferuje dynamicznie nazwane metody, które również wymagają poważnego przyzwyczajenia.

Po drugie, MVC niejawnie zakłada, że ​​tworzysz klasyczną witrynę sieci Web w stylu CRUD. Decyzje architektoniczne, a zwłaszcza generatory kodu, zostały stworzone z myślą o obsłudze tego typu aplikacji internetowych. Jeśli budujesz aplikację CRUD i chcesz przyjąć sprawdzoną architekturę (lub po prostu nie lubisz projektowania architektury), prawdopodobnie powinieneś rozważyć MVC. Jeśli jednak będziesz robić więcej niż CRUD i / lub masz wystarczające kompetencje w architekturze, MVC może wydawać się prostym kaftanem, dopóki naprawdę nie opanujesz podstawowego modelu routingu (który jest znacznie bardziej złożony niż po prostu routing w aplikacji WebForms). Nawet wtedy czułem, że zawsze walczę z modelem i martwię się o nieoczekiwane wyniki.

Po trzecie, jeśli nie obchodzi cię Linq (albo boisz się, że Linq-to-SQL zniknie, albo ponieważ uważasz, że Linq-to-Entities jest śmiesznie nadprodukowane i niewystarczające), to również nie chcesz przejść tę ścieżkę, ponieważ narzędzia do tworzenia szkieletów ASP.NET MVC są budowane wokół Linq (to był dla mnie zabójca). Model danych Railsów jest również dość niezdarny w porównaniu z tym, co można osiągnąć, jeśli masz doświadczenie w SQL (a zwłaszcza jeśli jesteś dobrze zorientowany w TSQL i procedurach składowanych!).

Po czwarte, zwolennicy MVC często wskazują, że widoki MVC są duchem bliższe modelowi HTML / CSS / AJAX sieci. Na przykład „pomocniki HTML” - małe wywołania kodu na stronie vew, które zamieniają zawartość i umieszczają ją w kontrolkach HTML - są znacznie łatwiejsze do zintegrowania z JavaScriptem niż kontrolkami formularzy sieci Web. Jednak ASP.NET 4.0 wprowadza możliwość nazywania formantów, a tym samym w znacznym stopniu eliminuje tę zaletę.

Po piąte, puryści MVC często wyśmiewają Viewstate. W niektórych przypadkach mają rację. Jednak Viewstate może być również doskonałym narzędziem i dobrodziejstwem dla produktywności. Dla porównania, obsługa Viewstate jest znacznie łatwiejsza niż próba zintegrowania kontrolek internetowych innych firm w aplikacji MVC. Podczas gdy integracja sterowania może stać się łatwiejsza dla MVC, wszystkie obecne wysiłki, które widziałem, cierpią z powodu konieczności zbudowania (nieco wrednego) kodu, aby połączyć te kontrolki z powrotem z klasą kontrolera widoku (to znaczy - aby obejść model MVC ).

Wnioski

Programowanie MVC podoba mi się na wiele sposobów (chociaż wolę Railsy od ASP.NET MVC z daleka). Myślę też, że ważne jest, abyśmy nie wpadli w pułapkę myślenia, że ​​ASP.NET MVC jest „anty-wzorcem” ASP.NET Web Forms. Są różne, ale nie całkowicie obce i na pewno jest miejsce dla obu.

Jednak wolę tworzenie formularzy sieci Web, ponieważ w przypadku większości zadań jest to po prostu łatwiejsze do wykonania (wyjątkiem jest generowanie zestawu formularzy CRUD). Wydaje się również, że MVC do pewnego stopnia cierpi z powodu nadmiaru teorii. Rzeczywiście, spójrz na wiele pytań zadawanych tutaj na SO przez ludzi, którzy znają ASP.NET zorientowany na strony, ale próbują MVC. Bez wyjątku jest dużo zgrzytania zębami, ponieważ programiści stwierdzają, że nie mogą wykonywać podstawowych zadań bez skakania przez obręcze lub znoszenia ogromnej krzywej uczenia się. To właśnie sprawia, że ​​formularze internetowe są lepsze od MVC w mojej książce: MVC sprawia, że ​​płacisz rzeczywistą cenę , aby uzyskać nieco większą testowalność lub, co gorsza, po prostu być postrzeganym jako fajny, ponieważ używaszNajnowsza technologia.

Aktualizacja: Zostałem mocno skrytykowany w sekcji komentarzy - niektóre z nich całkiem uczciwe. Dlatego spędziłem kilka miesięcy na nauce Railsów i ASP.NET MVC, aby upewnić się, że nie przegapiłem kolejnej wielkiej rzeczy! Oczywiście pomaga to również zapewnić wyważoną i odpowiednią odpowiedź na pytanie. Powinieneś wiedzieć, że powyższa odpowiedź jest głównym przepisaniem mojej początkowej odpowiedzi na wypadek, gdyby komentarze wydawały się niezsynchronizowane.

Kiedy przyglądałem się bliżej MVC, przez chwilę pomyślałem, że skończę z głównym mea culpa. W końcu doszedłem do wniosku, że chociaż myślę, że musimy poświęcić dużo więcej energii na architekturę i testowalność formularzy sieci Web, MVC naprawdę nie odpowiada na to wezwanie. Tak więc serdecznie dziękuję ludziom, którzy dostarczyli inteligentnej krytyki mojej początkowej odpowiedzi.

Jeśli chodzi o tych, którzy postrzegali to jako bitwę religijną i którzy nieustannie organizowali powodzie przeciwne, nie rozumiem, dlaczego się przejmujesz (ponad 20 głosów w dół w ciągu kilku sekund przy wielu okazjach z pewnością nie jest normalne). Jeśli czytasz tę odpowiedź i zastanawiasz się, czy w mojej odpowiedzi jest coś naprawdę „złego”, biorąc pod uwagę, że wynik jest znacznie niższy niż w przypadku niektórych innych odpowiedzi, możesz być pewien, że mówi ona więcej o kilku osobach, które się nie zgadzają, niż ogólne poczucie społeczność (ogólnie ta została pozytywnie oceniona ponad 100 razy).

Faktem jest, że wielu programistów nie dba o MVC i rzeczywiście nie jest to pogląd mniejszości (nawet w MS, jak zdają się wskazywać na blogach).

MVC zapewnia większą kontrolę nad wyjściem, a z tą kontrolą wiąże się większe ryzyko pisania źle zaprojektowanego kodu HTML, zupy tagów itp.

Ale jednocześnie masz kilka nowych opcji, których wcześniej nie miałeś ...

1. Większa kontrola nad stroną i elementami na niej zawartymi
2. Mniej „śmieci” w wynikach, takich jak ViewState lub zbyt długie identyfikatory elementów (nie zrozum mnie źle, podoba mi się ViewState)
3. Lepsza umiejętność programowania po stronie klienta z Javascriptem (ktoś ma aplikacje Web 2.0?)
4. Nie tylko MVC, ale JsonResult jest zgrabny ...

To nie znaczy, że nie możesz zrobić żadnej z tych rzeczy za pomocą WebForms, ale MVC to ułatwia.

Nadal używam formularzy internetowych, gdy muszę szybko utworzyć aplikację internetową, ponieważ mogę skorzystać z kontrolek serwera itp. Formularz sieciowy ukrywa wszystkie szczegóły tagów wejściowych i przycisków przesyłania.

Zarówno WebForms, jak i MVC są zdolne do absolutnego śmieci, jeśli jesteś nieostrożny. Jak zawsze, staranne planowanie i przemyślany projekt zaowocują wysokiej jakości aplikacją, niezależnie od tego, czy jest to MVC, czy WebForms.

[Aktualizacja]

Jeśli to też jest jakieś pocieszenie, MVC to tylko nowa, ewoluująca technologia firmy Microsoft. Było wiele postów, że WebForms nie tylko pozostaną, ale nadal będą rozwijane dla ...

http://haacked.com

http://www.misfitgeek.com

http://rachelappel.com

... i tak dalej...

Dla tych, którzy są zaniepokojeni trasą, którą podąża MVC, proponuję dać „chłopakom” swoją opinię. Wydaje się, że do tej pory słuchają!

Większość zastrzeżeń do ASP.NET MVC wydaje się skupiać wokół widoków, które są jednymi z najbardziej „opcjonalnych” i modułowych bitów w architekturze. NVelocity , NHaml , Spark , XSLT i inne silniki widzenia może być łatwo zamienione na zewnątrz (i to było coraz łatwiej z każdym wydaniu). Wiele z nich ma DUŻO bardziej zwięzłą składnię do wykonywania logiki prezentacji i formatowania, jednocześnie dając pełną kontrolę nad emitowanym kodem HTML.

Poza tym prawie każda krytyka wydaje się sprowadzać do tagowania <%%> w domyślnych widokach i do tego, jak „brzydki” jest. Ta opinia jest często zakorzeniona w podejściu do WebForms, które po prostu przenosi większość klasycznej brzydoty ASP do pliku związanego z kodem.

Nawet bez „niewłaściwego” wykonywania kodu za kodem, masz rzeczy takie jak OnItemDataBound w Repeaters, co jest równie brzydkie estetycznie, choćby w inny sposób, niż „tag soup”. Pętla foreach może być znacznie łatwiejsza do odczytania, nawet przy osadzaniu zmiennych w danych wyjściowych tej pętli, szczególnie jeśli przychodzisz do MVC z innych technologii innych niż ASP.NET. Zrozumienie pętli foreach wymaga znacznie mniej Google-fu, niż odkrycie, że sposobem na zmodyfikowanie tego jednego pola w repeaterze jest bałagan z OnItemDataBound (i szczurzym gniazdo sprawdzania, czy jest to właściwy element do zmiany.

Największym problemem związanym z „spaghetti” opartym na tagach ASP było raczej wpychanie takich rzeczy, jak połączenia z bazą danych, pomiędzy kodem HTML.

To, że stało się to przy użyciu <%%>, jest tylko korelacją z naturą spaghetti klasycznej ASP, a nie związkiem przyczynowym. Jeśli zachowasz logikę widoku do HTML / CSS / Javascript i minimalną logikę niezbędną do prezentacji , reszta to składnia.

Porównując dany fragment funkcjonalności z formularzami WebForms, upewnij się, że uwzględniono cały C # wygenerowany przez projektanta oraz kod C # związany z kodem wraz z kodem .aspx, aby mieć pewność, że rozwiązanie MVC w rzeczywistości nie jest dużo prostsze .

W połączeniu z rozsądnym wykorzystaniem częściowych widoków dla powtarzalnych fragmentów logiki prezentacji, może to być naprawdę ładne i eleganckie.

Osobiście chciałbym, żeby większość wczesnych samouczków koncentrowała się bardziej na tym końcu rzeczy niż prawie wyłącznie na sterowanym testach, odwróceniu kontroli itp. Podczas gdy eksperci sprzeciwiają się tym innym rzeczom, bardziej prawdopodobne jest, że ludzie w okopach sprzeciwić się „tag zupy”.

Niezależnie od tego jest to platforma, która wciąż jest w fazie beta. Mimo to coraz więcej wdrażania i programiści spoza Microsoft tworzą z nim rzeczywiste rzeczy niż większość technologii Microsoft-beta. W związku z tym szum ma tendencję do wydawania się, że jest dalej niż infrastruktura wokół niego (dokumentacja, wzorce wskazówek itp.). Fakt, że w tym momencie jest naprawdę użyteczny, tylko wzmacnia ten efekt.

<% if (Model.PreviousPost || Model.NextPost) { %>
    <div class="pager">
        <% if (Model.PreviousPost) { %>
            <span><% Html.ActionLink("<< " + Model.PreviousPost.Subject, "view")); %></span>
        <% } if (Model.NextPost) { %>
            <span><% Html.ActionLink(Model.NextPost.Subject + " >>", "view")); %></span>
        <% } %>
    </div>
<% } %>

Możesz napisać kolejny post z pytaniem, jak to zrobić, bez dołączania osadzonego kodu CSS.

UWAGA: ViewData.Model stanie się modelem w następnej wersji.

I przy pomocy kontroli użytkownika stanie się to

<% Html.RenderPartial("Pager", Model.PagerData) %>

gdzie PagerData jest inicjowana przez anonimowy konstruktor w programie obsługi akcji.

edycja: Jestem ciekawy, jak wyglądałaby Twoja implementacja WebForm dla tego problemu.

Nie jestem pewien, w którym momencie ludzie przestali dbać o swój kod.

HTML to najbardziej publiczna prezentacja Twojej pracy, jest wielu programistów, którzy używają Notatnika, Notatnika ++ i innych edytorów zwykłego tekstu do tworzenia wielu stron internetowych.

MVC polega na odzyskaniu kontroli z formularzy internetowych, pracy w środowisku bezstanowym i implementacji wzorca projektowego kontrolera widoku modelu bez całej dodatkowej pracy, która normalnie ma miejsce przy implementacji tego wzorca.

Jeśli chcesz mieć kontrolę, czysty kod i używać wzorców projektowych MVC, to jest dla Ciebie, jeśli nie lubisz pracować ze znacznikami, nie przejmuj się tym, jak zniekształcone są Twoje znaczniki, a następnie użyj formularzy sieci Web ASP.Net.

Jeśli nie lubisz któregoś z nich, na pewno będziesz wykonywać mniej więcej tyle samo pracy ze znacznikami.

EDYCJA I Powinienem również stwierdzić, że Web Forms i MVC mają swoje miejsce, w żaden sposób nie twierdziłem, że jeden jest lepszy od drugiego, tylko że każdy MVC ma siłę odzyskiwania kontroli nad znacznikami.

Myślę, że brakuje Ci niektórych rzeczy. Po pierwsze, nie ma potrzeby używania Response.Write, możesz użyć <%= %>tagów. Po drugie, możesz napisać własne rozszerzenia HtmlHelper do wykonywania typowych działań. Po trzecie, trochę formatowania bardzo pomaga. Po czwarte, wszystko to prawdopodobnie utknęłoby w kontrolce użytkownika, aby było współdzielone między kilkoma różnymi widokami, a zatem ogólny znacznik w widoku głównym jest bardziej przejrzysty.

Przyznam ci, że marża nadal nie jest tak zgrabna, jak by się chciało, ale można ją znacznie wyczyścić za pomocą niektórych zmiennych tymczasowych.

To nie jest takie złe i byłoby jeszcze lepiej, gdybym nie musiał formatować go dla SO.

 <%
    var PreviousPost = ViewData.Model.PreviousPost;
    var NextPost = ViewData.Model.NextPost;

    // Display the "Next and Previous" links
    if (PreviousPost != null || NextPost != null)
    {
  %>

 <div>

        <%= PreviousPost == null
                ? string.Empty
                : Html.ActionLinkSpan("<< " + PreviousPost.Subject,
                                "view",
                                new { id = PreviousPost.Id },
                                new { style = "float: left;" } ) %>
          <%= NextPost == null
                ? string.Empty
                : Html.ActionLinkSpan( NextPost.Subject + " >>",
                                   "view",
                                    new { id = NextPost.Id },
                                    new { style = "float: right;" } ) %>

  <div style="clear: both;" />
  </div>

  <% } %>

Dużą zaletą MVC jest to, że jest to struktura koncepcyjna, która istnieje od dawna i sprawdziła się jako produktywny, potężny sposób tworzenia zarówno aplikacji internetowych, jak i aplikacji dla stacji roboczych, które skalują się w poziomie i w pionie. Wraca bezpośrednio do Alto i Smalltalk. Microsoft spóźnia się na imprezę. To, co mamy teraz z ASP.NET MVC, jest naprawdę prymitywne, ponieważ jest tak wiele do nadrobienia; ale cholera, szybko i wściekle wypuszczają nowe wydania.

Jaka była wielka sprawa z Ruby on Rails? Railsy to MVC. Deweloperzy dokonali konwersji, ponieważ, pocztą pantoflową, stało się to sposobem na zwiększenie produktywności przez programistów.

To wielka sprawa; MVC i niejawne poparcie dla jQuery to punkty krytyczne dla firmy Microsoft, która akceptuje fakt, że neutralność platformy jest krytyczna. A co jest w tym neutralne, to fakt, że w przeciwieństwie do formularzy sieci Web Microsoft nie może zablokować Cię koncepcyjnie. Możesz wziąć cały swój kod C # i całkowicie zaimplementować go w innym języku (powiedzmy PHP lub java - nazywasz to), ponieważ to koncepcja MVC jest przenośna, a nie sam kod. (I pomyśl, jak wielkie jest to, że możesz wziąć swój projekt i zaimplementować go jako aplikację stacji roboczej z niewielkimi zmianami w kodzie i bez zmian w projekcie. Spróbuj tego z formularzami sieci Web).

Microsoft zdecydował, że Web Forms nie będzie kolejnym VB6.

Proszę spojrzeć na wpis Roba Conery'ego Spose I'll Just Say It: You Should Learn MVC

Dwie główne zalety platformy ASP.NET MVC w porównaniu z formularzami internetowymi to:

1. Testowalność - interfejs użytkownika i zdarzenia w formularzach internetowych są prawie niemożliwe do przetestowania. Dzięki ASP.NET MVC akcje kontrolera testów jednostkowych i renderowane widoki są łatwe. Wiąże się to z kosztami początkowymi, ale badania wykazały, że opłaca się to w dłuższej perspektywie, gdy przychodzi czas na refaktoryzację i utrzymanie aplikacji.
2. Lepsza kontrola nad renderowanym kodem HTML - stwierdzasz, że nie obchodzi Cię renderowany kod HTML, ponieważ nikt na niego nie patrzy. To słuszny zarzut, gdyby był to jedyny powód, dla którego należy mieć odpowiednio sformatowany HTML. Istnieje wiele powodów, dla których warto chcieć odpowiednio sformatowanego kodu HTML, w tym: SEO, możliwość częstszego korzystania z selektorów identyfikatorów (w css i javascript), mniejsze ślady na stronach z powodu braku stanu widoku i absurdalnie długie identyfikatory (ctl00_etcetcetc).

Teraz te powody nie sprawiają, że ASP.NET MVC jest lepszy ani gorszy niż formularze internetowe w sposób czarno-biały. ASP.NET MVC ma swoje mocne i słabe strony, podobnie jak formularze internetowe. Jednak większość skarg na ASP.NET MVC wydaje się wynikać raczej z braku zrozumienia, jak go używać, niż z rzeczywistych błędów we frameworku. Przyczyną, dla której Twój kod nie wygląda dobrze lub nie wygląda dobrze, może być to, że masz kilka lat doświadczenia w tworzeniu formularzy internetowych i tylko 1-2 miesiące doświadczenia w ASP.NET MVC.

Problem nie polega na tym, że ASP.NET MVC działa lub jest do bani, tylko dlatego, że jest nowy i nie ma zgody co do tego, jak go poprawnie używać. ASP.NET MVC oferuje znacznie bardziej szczegółową kontrolę nad tym, co dzieje się w aplikacji. To może sprawić, że niektóre zadania będą łatwiejsze lub trudniejsze, w zależności od tego, jak do nich podejdziesz.

Hej, również walczyłem z przejściem na MVC. Absolutnie nie jestem fanem klasycznego renderowania ASP i MVC, który przypomina mi wiele tamtych dni. Jednak im częściej używam MVC, tym bardziej na mnie rośnie. Jestem facetem od formularzy internetowych (jak wielu) i spędziłem kilka ostatnich lat, przyzwyczajając się do pracy z datagridami itp. Z MVC, który został zabrany. Odpowiedzią są klasy pomocnika HTML.

Niedawno spędziłem 2 dni próbując znaleźć najlepszy sposób dodania stronicowania do „siatki” w MVC. Teraz dzięki formularzom internetowym mogę to szybko rozwiązać. Ale powiem tak ... kiedy już zbudowałem klasy pomocnika stronicowania dla MVC, stało się to niezwykle proste w implementacji. Dla mnie nawet łatwiejsze niż formularze internetowe.

Biorąc to pod uwagę, myślę, że MVC będzie znacznie bardziej przyjazny dla programistów, gdy będzie dostępny spójny zestaw pomocników HTML. Myślę, że w najbliższej przyszłości zaczniemy widzieć w sieci mnóstwo klas pomocniczych HTML.

To zabawne, ponieważ to właśnie powiedziałem, kiedy po raz pierwszy zobaczyłem formularze internetowe.

Przyznam, że nie mam jeszcze asp.net MVC. Próbuję go użyć w pobocznym projekcie, który robię, ale działa to dość wolno.

Poza tym, że nie mogę robić rzeczy, które były tak łatwe do zrobienia w formularzach internetowych, zauważam zupę tagów. Z tej perspektywy naprawdę wydaje się cofać o krok. Mam nadzieję, że kiedy się nauczę, będzie lepiej.

Jak dotąd zauważyłem, że głównym powodem używania MVC jest uzyskanie pełnej kontroli nad HTML. Czytałem również, że asp.net MVC jest w stanie obsłużyć więcej stron szybciej niż formularze internetowe i prawdopodobnie w związku z tym rozmiar pojedynczej strony jest mniejszy niż przeciętna strona formularzy sieci Web.

Naprawdę nie obchodzi mnie, jak wygląda mój kod HTML, o ile działa w głównych przeglądarkach, ale obchodzi mnie, jak szybko ładują się moje strony i jaką przepustowość zajmują.

Chociaż w pełni zgadzam się, że jest to brzydki znacznik, myślę, że używanie brzydkiej składni widoku do odpisywania ASP.NET MVC jako całości jest nieuczciwe. Microsoftowi najmniej uwagi poświęcił składnia widoku i spodziewam się, że wkrótce zostanie coś z tym zrobione.

Inne odpowiedzi omawiały zalety MVC jako całości, więc skupię się na składni widoku:

Zachęta do korzystania z Html.ActionLink i innych metod generujących HTML jest krokiem w złym kierunku. To trąci kontroli serwera i, jak dla mnie, rozwiązuje problem, który nie istnieje. Jeśli mamy generować tagi z kodu, to po co w ogóle zawracać sobie głowę używaniem HTML? Możemy po prostu użyć DOM lub innego modelu i zbudować naszą zawartość w kontrolerze. Ok, to brzmi źle, prawda? O tak, oddzielenie obaw, dlatego mamy pogląd.

Myślę, że właściwym kierunkiem jest uczynienie składni widoku jak najbardziej podobnej do HTML. Pamiętaj, że dobrze zaprojektowany MVC powinien nie tylko zapewniać oddzielenie kodu od treści, ale także umożliwiać usprawnienie produkcji dzięki zatrudnianiu osób, które są ekspertami w układaniu widoków (nawet jeśli nie znają ASP.NET), a następnie później jako programista możesz wkroczyć i sprawić, by makieta widoku była faktycznie dynamiczna. Można to zrobić tylko wtedy, gdy składnia widoku wygląda bardzo podobnie do HTML, dzięki czemu osoby zajmujące się układem mogą używać programu DreamWeaver lub innego popularnego narzędzia do projektowania. Być może budujesz dziesiątki lokalizacji jednocześnie i musisz skalować w ten sposób, aby zwiększyć wydajność produkcji. Podam przykład, jak mogłem zobaczyć działający widok „język”:

<span mvc:if="ViewData.Model.ShowPrevious" style="float: left;">
    <a mvc:inner="ViewData.Model.PreviousPost.Subject" href="view/{ViewData.Model.PreviousPost.Id}">sample previous subject</a>
</span> 
<span mvc:if="ViewData.Model.ShowNext" style="float: left;">
    <a mvc:inner="ViewData.Model.NextPost.Subject" href="view/{ViewData.Model.NextPost.Id}">sample next subject</a>
</span> 
<div mvc:if="ViewData.Model.ShowNextOrPrevious" style="clear: both;" />

Ma to kilka zalet:

• wygląda lepiej
• bardziej zwięzłe
• brak funky przełączania kontekstu między znacznikami HTML i <%%>
• łatwe do zrozumienia słowa kluczowe, które są oczywiste (nawet osoba nie będąca programistą mogłaby to zrobić - dobre do równoległości)
• jak najwięcej logiki przeniesiono z powrotem do kontrolera (lub modelu)
• brak generowanego kodu HTML - ponownie, dzięki temu bardzo łatwo jest wejść i wiedzieć, gdzie coś stylizować, bez konieczności majstrowania przy HTML. metody
• kod zawiera przykładowy tekst, który renderuje się po załadowaniu widoku jako zwykły HTML w przeglądarce (znowu, dobry dla osób zajmujących się układami)

Więc co dokładnie robi ta składnia?

mvc: inner = "" - cokolwiek jest w cudzysłowach, zostanie ocenione, a wewnętrzny kod HTML tagu zostanie zastąpiony wynikowym ciągiem. (Nasz przykładowy tekst zostanie zastąpiony)

mvc: external = "" - cokolwiek jest w cudzysłowach, zostanie ocenione, a zewnętrzny kod HTML tagu zostanie zastąpiony wynikowym ciągiem. (Ponownie, przykładowy tekst zostanie zastąpiony.)

{} - służy do wstawiania wyników wewnątrz atrybutów, podobnie jak <% =%>

mvc: if = "" - insde qoutes jest wyrażeniem logicznym, które ma być ewaluowane. Zamknięcie if oznacza miejsce, w którym tag HTML zostaje zamknięty.

mvc: else

mcv: elseif = "" - ...

mvc: foreach

Teraz mogę mówić tylko za siebie:

IMO, jeśli jesteś zagorzałym (czymkolwiek), konwersja nie jest dla ciebie. Jeśli kochasz WebForms, to dlatego, że możesz osiągnąć to, czego potrzebujesz, i to też jest celem każdego.

Webforms dobrze sobie radzi z wyodrębnianiem kodu HTML od programisty . Jeśli to Twój cel, trzymaj się formularzy internetowych. Masz całą wspaniałą funkcjonalność „kliknij i przeciągnij”, która sprawiła, że ​​programowanie na komputery stacjonarne jest tym, czym jest dzisiaj. Istnieje wiele dołączonych elementów sterujących (plus bogactwo elementów sterujących stron trzecich), które mogą zapewniać różne funkcje. Możesz przeciągnąć „siatkę”, która jest bezpośrednio powiązana ze źródłem danych z Twojej bazy danych; jest wyposażony w wbudowaną edycję, stronicowanie itp.

W chwili obecnej ASP.NET MVC jest bardzo ograniczony pod względem kontroli innych firm. Więc znowu, jeśli lubisz szybkie tworzenie aplikacji, w którym jest wiele funkcji, nie powinieneś próbować się konwertować.

Biorąc to wszystko pod uwagę, w tym miejscu ASP.NET świeci: - TDD. Kod nie jest testowalny, powiedział Nuff.

• Rozdzielenie obaw. To jest kręgosłup wzorca MVC. Jestem w pełni świadomy, że możesz to osiągnąć w formularzach sieci Web. Jednak lubię narzuconą strukturę. W formularzach sieci Web zbyt łatwo było mieszać projekt i logikę. ASP.NET MVC ułatwia różnym członkom zespołu pracę nad różnymi sekcjami aplikacji.

• Pochodzę z innego miejsca: Moje tło to CakePHP i Ruby on Rails. Tak więc jest jasne, gdzie leży moja stronniczość. Chodzi po prostu o to, z czym czujesz się komfortowo.

• Krzywa uczenia się: aby rozwinąć ostatni punkt; Nienawidziłam pomysłu „szablonów” w celu zmiany funkcjonalności różnych elementów. Nie podobał mi się fakt, że duża część projektu została wykonana w kodzie pliku. To była jeszcze jedna rzecz do nauczenia się, kiedy byłem już dobrze zaznajomiony z HTML i CSS. Jeśli chcę coś zrobić w „elemencie” na stronie, wsuwam „div” lub „span”, przyklejam do niego identyfikator i zaczynam. W formularzach internetowych musiałbym zbadać, jak to zrobić.

• Obecny stan „projektowania” sieci: Biblioteki JavaScript, takie jak jQuery, stają się coraz bardziej powszechne. Sposób, w jaki formularze sieci Web manipulują identyfikatorami, tylko utrudnia implementację (poza programem Visual Studio).

• Więcej separacji (projekt): ponieważ duża część projektu jest połączona z kontrolkami, praca nad projektem formularzy sieci Web byłaby bardzo trudna dla zewnętrznego projektanta (bez formularzy sieci Web). Web Forms został stworzony, aby być końcem wszystkiego i być wszystkim.

Ponownie, wiele z tych powodów wynika z mojej nieznajomości z Web Forms. Projekt formularzy sieci Web (jeśli został zaprojektowany odpowiednio) może mieć „większość” zalet ASP.NET MVC. Ale to jest zastrzeżenie: „Jeśli dobrze zaprojektowane”. A to jest coś, czego nie wiem, jak to zrobić w formularzach sieci Web.

Jeśli wykonujesz znakomitą pracę w Formularzach internetowych, jesteś wydajny i to działa dla Ciebie, to jest miejsce, w którym powinieneś zostać.

Zasadniczo zrób szybką recenzję obu (spróbuj znaleźć bezstronne źródło [powodzenia]) z listą zalet i wad, oceń, który z nich pasuje do twoich celów i wybierz na tej podstawie.

Podsumowując, wybierz ścieżkę najmniejszego oporu i najwięcej korzyści, aby osiągnąć swoje cele. Web Forms to bardzo dojrzała platforma, która będzie tylko ulepszana w przyszłości. ASP.NET MVC to po prostu kolejna alternatywa (do rysowania w Ruby on Rails i programistach CakePHP, takich jak ja: P)

JSP Java EE wyglądały tak, gdy zostały po raz pierwszy zaproponowane - brzydki kod skryptletu.

Następnie zaoferowali biblioteki tagów, aby uczynić je bardziej HTML-owymi. Problem polegał na tym, że każdy mógł napisać bibliotekę znaczników. Niektóre wyniki były katastrofalne, ponieważ ludzie osadzili wiele logiki (a nawet stylu) w bibliotekach tagów, które generowały HTML.

Myślę, że najlepszym rozwiązaniem jest JSP Standard Tag Library (JSTL). Jest „standardowa”, zawiera znaczniki HTML i zapobiega wprowadzaniu logiki do stron.

Dodatkową korzyścią jest to, że zachowuje tę linię demarkacyjną między projektantami stron internetowych i programistami. Dobre strony, które widzę, są projektowane przez ludzi z wyczuciem estetycznym i projektowaniem pod kątem użyteczności. Układają strony i CSS i przekazują je programistom, którzy dodają dynamiczne bity danych. Mówiąc jako programista, któremu brakuje tych darów, myślę, że oddajemy coś ważnego, gdy prosimy programistów o pisanie stron internetowych od zupy po orzechy. Flex i Silverlight będą miały ten sam problem, ponieważ jest mało prawdopodobne, aby projektanci dobrze znali JavaScript i AJAX.

Gdyby .NET miał ścieżkę podobną do JSTL, radziłbym, aby się tym zajął.

Pomyślałem, że udostępnię, jak ten przykład wygląda z nowym, błyszczącym aparatem widoku Razor, który jest domyślny od czasu ASP .NET MVC 3.

@{ 
    var prevPost = ViewData.Model.PreviousPost;
    var nextPost = ViewData.Model.NextPost;
}

@if (prevPost != null || nextPost != null) {
    <div>
        @if (prevPost != null) {
            <span style="float: left;">
                @Html.ActionLink("<< " + prevPost.Subject, "view", new { id = prevPost.Id })
            </span>
        }
        @if (nextPost != null) {
            <span style="float: left;">
                @Html.ActionLink(nextPost.Subject + " >>", "view", new { id = nextPost.Id })
            </span>
        }
        <div style="clear: both;" />
    </div>
}

Masz z tym jakiś problem?
Nie powinieneś także wstawiać swoich stylów CSS, prawda? I dlaczego sprawdzasz nieważność w trzech miejscach zamiast tylko w dwóch? Bardzo divrzadko boli. Oto jak bym to zrobił:

<div>
    @if (prevPost != null) {
        @Html.ActionLink("<< " + prevPost.Subject, "view",
            new { id = prevPost.Id, @class = "prev-link" })
    }
    @if (nextPost != null) {
        @Html.ActionLink(nextPost.Subject + " >>", "view",
            new { id = nextPost.Id, @class = "next-link" })
    }
    <div class="clear" />
</div>

Nie mogę rozmawiać bezpośrednio z projektem ASP.NET MVC, ale ogólnie rzecz biorąc frameworki MVC zdominowały tworzenie aplikacji internetowych , ponieważ

1. Oferują formalne oddzielenie operacji bazodanowych, „logiki biznesowej” i prezentacji

2. Oferują wystarczającą elastyczność w widoku, aby umożliwić programistom dostosowywanie ich HTML / CSS / Javascript do pracy w wielu przeglądarkach i przyszłych wersjach tych przeglądarek

To ten ostatni fragment jest najważniejszy. Dzięki formularzom internetowym i podobnym technologiom polegasz na swoim dostawcy, który napisze za Ciebie HTML / CSS / Javascript. To potężne narzędzie, ale nie masz gwarancji, że aktualna wersja formularzy internetowych będzie działać z następną generacją przeglądarek internetowych.

To jest siła widoku. Masz pełną kontrolę nad kodem HTML swojej aplikacji. Wadą jest to, że musisz być na tyle zdyscyplinowany, aby utrzymać logikę w swoich widokach na minimum, a kod szablonu był tak prosty, jak to tylko możliwe.

Więc to jest kompromis. Jeśli formularze internetowe działają dla Ciebie, a MVC nie, nadal używaj formularzy internetowych

Większość mojej frustracji wynika z braku wiedzy, jak robić rzeczy „prawidłowo”. Odkąd została wydana jako wersja zapoznawcza, wszyscy mieliśmy trochę czasu, aby przyjrzeć się temu, ale one trochę się zmieniły. Na początku byłem naprawdę sfrustrowany, ale framework wydaje się wystarczająco działający, aby umożliwić mi dość szybkie tworzenie bardzo złożonych interfejsów użytkownika (czytaj: JavaScript). Rozumiem, że możesz to zrobić za pomocą formularzy internetowych, tak jak robiłem to wcześniej, ale próba poprawnego renderowania wszystkiego była ogromnym problemem. Wiele razy korzystałem z repeatera do kontrolowania dokładnej wydajności i kończyłem z dużą ilością bałaganu spaghetti, który masz powyżej.

Aby nie mieć tego samego bałaganu, używałem kombinacji domeny, warstw usług i DTO, aby przenieść się do widoku. Połącz to ze iskrą, silnikiem widoku i robi się naprawdę fajnie. Konfiguracja zajmuje trochę czasu, ale kiedy już ją uruchomisz, widziałem duży krok w złożoności moich aplikacji wizualnie, ale jest to tak śmierdząco proste do wykonania kodu.

Prawdopodobnie nie zrobiłbym tego dokładnie w ten sposób, ale oto twój przykład:

<if condition="myDtp.ShowPager">
  <div>
    <first />
    <last />
    <div style="clear: both;" />
  </div>
</if>

To całkiem możliwe do utrzymania, testowalne i smakuje pysznie w mojej zupie kodu.

Wniosek jest taki, że czysty kod jest naprawdę możliwy, ale jest to duża zmiana w stosunku do sposobu, w jaki robiliśmy rzeczy. Nie sądzę jednak, żeby wszyscy jeszcze to rozumieli. Wiem, że wciąż to rozumiem ...

Niedawno opublikowana książka Steve'a Sandersona „Pro ASP.NET MVC” [1] [2] firmy Apress sugeruje inną alternatywę - utworzenie niestandardowego rozszerzenia HtmlHelper. Jego próbka (z rozdziału 4 na stronie 110) wykorzystuje przykład listy stronicowanej, ale można ją łatwo dostosować do twojej sytuacji.

public static string PostNavigator(this HtmlHelper html, Post previous, Post next, Func<int, string> pageUrl)
{
    StringBuilder result = new StringBuilder();

    if (previous != null || next != null)
    {
        result.Append("<div>");

        if (previous != null)
        {
            result.Append(@"<span class=""left"">");
            TagBuilder link = new TagBuilder("a");
            link.MergeAttribute("href", pageUrl(previous.Id));
            link.InnerHtml = String.Format("<< {0}", html.Encode(previous.Subject));
            result.Append(link.ToString());
            result.Append("</span>");
        }

        if (next != null)
        {
            if (previous != null)
            {
                result.Append(" ");
            }

            result.Append(@"<span class=""right"">");
            TagBuilder link = new TagBuilder("a");
            link.MergeAttribute("href", pageUrl(next.Id));
            link.InnerHtml = String.Format("{0} >>", html.Encode(next.Subject));
            result.Append(link.ToString());
            result.Append("</span>");
        }

        result.Append("</div>");
    }

    return result.ToString();
}

Możesz to nazwać w swoim widoku za pomocą kodu mniej więcej tak:

<%= Html.PostNavigator(ViewData.Model.PreviousPost, ViewData.Model.NextPost, id => Url.Action("View", new { postId = id })) %>

[1] http://blog.codeville.net/2009/04/29/now-published-pro-aspnet-mvc-framework-apress/

[2] http://books.google.com/books?id=Xb3a1xTSfZgC

Miałem nadzieję, że zobaczę post od Phila Haacka, ale nie było go tutaj, więc wyciąłem go i wklejam z http://blog.wekeroad.com/blog/i-spose-ill-just-say-it-you-should -learn-mvc / w sekcji komentarzy

Haacked - 23 kwietnia 2009 - Rob, jesteś buntownikiem! :) Uważam to za zabawne, gdy ludzie piszą kod spaghetti w MVC, a potem mówią „patrz! Spaghetti!” Hej, mogę też pisać kod spaghetti w formularzach sieci Web! Mogę napisać to w railsach, PHP, Javascript, Javascript, ale nie w Lispie. Ale tylko dlatego, że nie mogę jeszcze nic napisać w Lisp. A kiedy piszę kod spaghetti, nie patrzę na swój talerz ponuro, oczekując makaronu. Często ludzie porównując to z klasycznymi ASP, mają tendencję do mieszania obaw z klasycznymi ASP. Strony miałyby logikę widoku z obsługą danych wejściowych użytkownika zmieszaną z kodem modelu i logiką biznesową, a wszystko to w jednym. O to chodziło w tym spaghetti! Mieszanie to wszystko w jednym wielkim bałaganie. Dzięki ASP.NET MVC, jeśli będziesz postępować zgodnie ze wzorcem, prawdopodobnie to zrobisz. Tak, nadal możesz mieć w widoku fragment kodu, ale miejmy nadzieję, że to wszystko. Wzorzec zachęca, aby nie umieszczać tam kodu interakcji użytkownika. Umieść go w kontrolerze. Umieść kod modelu w klasie modelu. Tam. Żadnego spaghetti. Teraz jest O-Toro Sushi. :)

Ja też; Wolałbym spędzać czas na Silverlight zamiast ASP.NET MVC. Wypróbowałem MVC 1.0 i kilka dni temu zapoznałem się z najnowszą wersją 2.0 Beta 1.

Nie czuję, że ASP.NET MVC jest lepszy niż formularz internetowy. Punktem sprzedaży MVC są:

1. Jednostka (test)
   
2. Oddziel projekt (widok) i logikę (kontroler + model)
   
3. Brak stanu wyświetlania i lepsze zarządzanie identyfikatorami elementów
   
4. RESTful URL i więcej ...

Jednak formularz sieciowy, wykorzystując związany z kodem motyw, motyw, skórkę i zasoby, jest już idealny do oddzielenia projektu od logiki.

Viewstate: zarządzanie identyfikatorami klientów będzie dostępne w ASP.NET 4.0. Martwię się tylko o testy jednostkowe, ale testy jednostkowe nie są wystarczającym powodem, aby przejść do ASP.NET MVC z formularza internetowego.

Może mogę powiedzieć: ASP.NET MVC nie jest zły, ale webform już wystarczy.

Używam MVC od czasu premiery Preview 3 i chociaż wciąż ma bóle rozwojowe, pomaga całkiem w obszarze rozwoju zespołu. Spróbuj, gdy trzy osoby będą pracować nad jedną stroną z formularzami internetowymi, a zrozumiesz pojęcie uderzania głową w ścianę. Mogę współpracować z programistą, który rozumie elementy projektu na stronie widoku, i naszym rezydentem z bogiem Linq, aby model działał, podczas gdy ja składam wszystko razem w kontrolerze. Nigdy nie byłem w stanie rozwinąć się w królestwie, w którym rozdzielenie obaw było tak łatwe do osiągnięcia.

Największy punkt sprzedaży ASP.Net MVC - StackOverflow działa na stosie MVC.

Biorąc to pod uwagę ... Twój kod jest o wiele ładniejszy niż to, co zwykle robię ze stroną widoku. Ponadto jeden z facetów, z którymi pracuję, pracuje nad opakowaniem pomocnika HTML w bibliotekę tagów. Zamiast <% = Html.RandomFunctionHere ()%> działa jak

<hh: randomfunction />

Mam tylko nadzieję, że zespół MVC kiedyś to załatwi, ponieważ jestem pewien, że wykonaliby lepszą robotę.

Użyj wzorca fasady, aby zawinąć całą logikę dla wszystkich danych, które chcesz wyświetlić, a następnie użyj jej jako ogólnego w swoim widoku, a potem ... koniec z kodem spaghetti. http://en.wikipedia.org/wiki/Design_pattern_(computer_science)

Jeśli potrzebujesz dodatkowej pomocy, cgardner2020@gmail.com

Implementacja ASP.NET MVC jest okropna. Produkt zwykły jest do niczego. Widziałem kilka jego demonstracji i wstydzę się MSFT ... Jestem pewien, że ludzie, którzy to napisali, są mądrzejsi ode mnie, ale to prawie tak, jakby nie wiedzieli, co to jest Model-View-Controller .

Znam tylko osoby, które próbują wdrożyć MVC, to ludzie, którzy lubią próbować nowych rzeczy z MSFT. W pokazach, które widziałem, prezenter miał przepraszający ton ...

Jestem wielkim fanem MSFT, ale muszę powiedzieć, że nie widzę powodu, aby zawracać sobie głowę ich implementacją MVC. Albo użyj formularzy sieci Web, albo użyj jquery do tworzenia stron internetowych, nie wybieraj tego obrzydliwości.

EDYTOWAĆ:

Celem wzorca projektowego architektury Model-View-Controller jest oddzielenie domeny od prezentacji od reguł biznesowych. Użyłem tego wzorca z powodzeniem w każdym wdrożonym przeze mnie projekcie Web Forms. Produkt ASP.NET MVC nie nadaje się dobrze do rzeczywistego wzorca projektu architektonicznego.