Хтось поряд зі мною просто НЕ отримує ASP.NET MVC? [зачинено]

Я співаюсь з ASP.NET MVC ще з CTP, і мені подобається багато речей, які вони робили, але є речі, які я просто не отримую.

Наприклад, я завантажив beta1, і я збираю трохи особистого сайту / резюме / блогу з ним. Ось фрагмент із подання 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> <%
        }
    %>

Огидно! (Також зауважте, що в HTML є тимчасовий HTML-заповнювач, я буду робити фактичний дизайн, коли функціонал працює) .

Чи я щось роблю не так? Тому що я провів багато темних днів у класичному ASP, і цей суп з тегами мені дуже нагадує про це.

Усі пропонують, як можна зробити чистіший HTML. Вгадай що? 1% усіх людей дивляться на вихідний HTML. Мені не байдуже, чи веб-форми зіпсують мій відступ у виведеному HTML, якщо у мене є код, який легко підтримувати ... Це не так!

Отже, конвертуйте мене, хлопець із жорстких веб-форм, чому я повинен відмовитись від своїх добре сформованих ASPX-сторінок для цього?

Редагувати: Жирний рядок "temp Html / css", щоб люди стфували про це.

Порівняно з веб-формами, MVC є одночасно підходом нижчого рівня до генерування HTML з більшим контролем над публікацією сторінки та підходом архітектури більш високого рівня. Дозвольте мені захопити Web Forms та MVC і покажу, чому я вважаю, що порівняння надає перевагу веб-формам у багатьох ситуаціях - до тих пір, поки ви не потрапите в якісь класичні пастки веб-форм.

Веб-форми

У моделі Web Forms ваші сторінки відповідають запиту сторінки у веб-переглядачі. Таким чином, якщо ви скеровуєте користувача до списку Книг, ви, ймовірно, матимете сторінку десь під назвою "Booklist.aspx", на яку ви будете спрямовувати його. На цій сторінці ви повинні надати все необхідне для показу цього списку. Сюди входить код для отримання даних, застосування будь-якої логіки бізнесу та відображення результатів. Якщо якась архітектурна або маршрутизаційна логіка впливає на сторінку, вам доведеться також кодувати архітектурну логіку на сторінці. Хороша розробка веб-форм, як правило, передбачає розробку набору допоміжних класів в окремій (тестованій для блоку) DLL. Ці класи будуть обробляти бізнес-логіку, доступ до даних та архітектурні / маршрутизаційні рішення.

MVC

MVC займає більш "архітектурний" погляд на розробку веб-додатків: пропонує стандартизований ешафот, на якому можна будувати. Він також пропонує інструменти для автоматичного генерування класів моделей, перегляду та контролерів у межах встановленої архітектури. Наприклад, і в Ruby on Rails (просто "Rails" звідси), і в ASP.NET MVC ви завжди будете починати зі структури каталогів, яка відображає їх загальну модель архітектури веб-додатків. Щоб додати вигляд, модель та контролер, ви скористаєтесь командою на кшталт Rails "Сценарій Rails / генерувати риштування {modelname}" (ASP.NET MVC пропонує подібні команди в IDE). У результуючому класі контролера знайдуться методи ("Дії") для Index (показ списку), Show, New і Edit та Destroy (принаймні у Rails, MVC схожий). За замовчуванням ці "

Розташування каталогів та файлів є важливим у MVC. Наприклад, в ASP.NET MVC метод Index для об’єкта "Book", ймовірно, матиме лише один рядок: "Return View ();" Завдяки магії MVC це перетворить модель Книги на сторінку "/View/Books/Index.aspx", де ви знайдете код для відображення книг. Підхід Рейлса схожий, хоча логіка трохи більш чітка і менш "магія". Сторінка перегляду в додатку MVC зазвичай простіша, ніж сторінка Web Forms, оскільки їм не потрібно так сильно хвилюватися щодо маршрутизації, ділової логіки чи обробки даних.

Порівняння

Переваги MVC полягають у чистому розділенні проблем та більш чистій, більш HTML-CSS / AJAX / Javascript-орієнтованій моделі для отримання результатів. Це підвищує доказовість, забезпечує більш стандартизований дизайн і відкриває двері до більш веб-сайту типу "Web 2.0".

Однак є і деякі суттєві недоліки.

По-перше, хоча демонструвати сайт легко, але загальна архітектурна модель має значну криву навчання. Коли вони кажуть "Конвенція про конфігурацію", це звучить добре - доки ти не зрозумієш, що ти маєш конвенцію, яку варто навчитись книзі. Крім того, часто трохи розум , щоб зрозуміти, що відбувається , тому що ви будете покладатися на магії , а не явні викликів. Наприклад, що "View View ();" зателефонувати вище? Точний же дзвінок можна знайти в інших акціях, але вони ходять у різні місця. Якщо ви розумієте конвенцію MVCтоді ви знаєте, чому це робиться. Однак це, безумовно, не є прикладом хорошого іменування або легко зрозумілого коду, а новим розробникам набагато важче підібрати, ніж Web Forms (це не лише думка: у минулому році я літній стажер вивчав веб-форми та MVC цього року та різниці в продуктивності були виражені - на користь Web Forms). До речі, Rails є дещо кращим у цьому плані, хоча Ruby on Rails має динамічно названі методи, які також потребують серйозного звикання.

По-друге, MVC неявно передбачає, що ви створюєте класичний веб-сайт у стилі CRUD. Архітектурні рішення, а особливо генератори коду, створені для підтримки такого типу веб-додатків. Якщо ви будуєте додаток CRUD і хочете прийняти перевірену архітектуру (або просто не подобається дизайн архітектури), то, ймовірно, слід врахувати MVC. Однак, якщо ви робите більше, ніж CRUD та / або ви досить грамотно знаєте архітектуру, то MVC може відчувати себе прямолінійною курткою, поки ви справді не освоїте базову модель маршрутизації (що значно складніше, ніж просто маршрутизація в додатку WebForms). Вже тоді я відчував, що завжди боровся з моделлю і переживаю за несподівані результати.

По-третє, якщо вам не байдуже Linq (або тому, що ви боїтесь, що Linq-SQL зникне, або тому, що ви вважаєте, що Linq-to-Entities смішно переробляється і працює під напругою), ви також не хочете пройти цей шлях, оскільки навколо Linq створено інструменти для риштування ASP.NET MVC (це було вбивцею для мене). Модель даних Rails також досить незграбна в порівнянні з тим, чого ви можете досягти, якщо у вас є досвід SQL (особливо, якщо ви добре розбираєтесь у TSQL і зберігаєте процедури!).

По-четверте, прихильники MVC часто зазначають, що погляди MVC за духом ближче до моделі HTML / CSS / AJAX в Інтернеті. Наприклад, "HTML Helpers" - маленькі дзвінки з коду на вашій веб-сторінці, які розміщують вміст і розміщують його в елементах керування HTML - набагато простіше інтегруватися з Javascript, ніж елементи керування Web Forms. Однак ASP.NET 4.0 вводить можливість називати свої елементи управління і таким чином значною мірою усуває цю перевагу.

По-п’яте, пуристи MVC часто висміюють Viewstate. У деяких випадках вони мають право це робити. Однак Viewstate також може бути чудовим інструментом і користю для продуктивності. Для порівняння, обробляти Viewstate набагато простіше, ніж намагатися інтегрувати сторонні веб-елементи управління в додаток MVC. Хоча інтеграція управління може бути полегшена для MVC, всі поточні зусилля, які я бачив, страждають від необхідності побудувати (дещо потворний) код, щоб зв’язати ці елементи управління з класом контролера подання (тобто - працювати навколо моделі MVC ).

Висновки

Мені подобається розробка MVC багато в чому (хоча я віддаю перевагу Rails до ASP.NET MVC з дальнього пострілу). Я також думаю, що важливо, щоб ми не потрапляли в пастку думок, що ASP.NET MVC є "антидіаграмою" веб-форм ASP.NET. Вони різні, але не зовсім чужі і, безумовно, є місця для обох.

Однак я віддаю перевагу розробці веб-форм, тому що для більшості завдань просто простіше виконати справи (виняток становить генерація набору форм CRUD). MVC також певною мірою страждає від надлишку теорії. Дійсно, подивіться на багато питань, які тут задають на SO, люди, які знають ASP.NET, орієнтований на сторінку, але намагаються MVC. Без винятку, зуби сильно стискаються, оскільки розробники виявляють, що вони не можуть виконувати основні завдання, не перестрибуючи обручі або переносячи величезну криву навчання. Це те, що робить веб-форми вищими за MVC в моїй книзі: MVC змушує вас заплатити реальну світову ціну , щоб отримати трохи більше перевіреності або, що ще гірше, просто вважати себе крутим, оскільки ви використовуєтеновітні технології.

Оновлення: у розділі коментарів я сильно критикувався - деякі з них цілком справедливі. Таким чином, я витратив кілька місяців на вивчення Rails та ASP.NET MVC, щоб переконатися, що я насправді не пропустив наступну велику річ! Звичайно, це також допомагає забезпечити збалансовану та відповідну відповідь на питання. Ви повинні знати, що наведена відповідь є основним переписом моєї початкової відповіді на випадок, якщо коментарі здаються синхронізованими.

Поки я пильніше придивлявся до MVC, я на деякий час подумав, що закінчуся великою мірою. Врешті-решт я зробив висновок, що, хоча я думаю, що нам потрібно витратити набагато більше енергії на архітектуру та перевірку веб-форм, MVC насправді не відповідає на дзвінок для мене. Отже, щире "дякую" людям, які надавали розумні критики моєї первинної відповіді.

Щодо тих, хто сприймав це як релігійну битву і хто без зусиль спроектував повені, я не розумію, чому ви турбуєтесь (20+ голосів за кілька разів один за одним багато разів, звичайно, це не нормально). Якщо ви читаєте цю відповідь і цікавитесь, чи є щось справді "неправильне" у моїй відповіді, враховуючи, що оцінка набагато нижча, ніж деякі інші відповіді, будьте впевнені, що вона говорить більше про кілька людей, які не згодні, ніж загальний сенс громада (загалом ця група була оскаржена набагато більше 100 разів).

Справа в тому, що багато розробників не піклуються про MVC, і, справді, це не є меншинним поглядом (навіть у межах MS, як показують блоги).

MVC надає вам більше контролю над результатами, і за допомогою цього контролю виникає більший ризик написання погано розробленого HTML, супу з тегами тощо ...

Але в той же час у вас є кілька нових варіантів, яких у вас раніше не було ...

1. Більше контролю над сторінкою та її елементами
2. Менше "мотлоху" у вашому висновку, як ViewState або надмірно довгі ідентифікатори елементів (не зрозумійте мене неправильно, мені подобається ViewState)
3. Краща можливість програмування на стороні клієнта за допомогою Javascript (Web 2.0 додатків кому?)
4. Не лише MVC, але й JsonResult чутливий ...

Тепер це не означає, що ви не можете робити будь-яку з цих речей за допомогою WebForms, але MVC робить це простіше.

Я все ще використовую WebForms, коли мені потрібно швидко створити веб-додаток, оскільки я можу скористатися серверними елементами управління тощо.

І WebForms, і MVC здатні до сміття, якщо ви недбалі. Як завжди, ретельне планування та продуманий дизайн призведе до якісного застосування, незалежно від того, чи це MVC чи WebForms.

[Оновлення]

Якщо це теж будь-яка втіха, MVC - це лише нова технологія Microsoft, що розвивається. Існує багато публікацій, що WebForms не тільки залишаться, але продовжують розроблятись для ...

http://haacked.com

http://www.misfitgeek.com

http://rachelappel.com

... і так далі...

Для тих, хто стурбований маршрутом MVC, я б запропонував "хлопцям" надати свої відгуки. Вони, здається, слухають поки що!

Більшість заперечень проти ASP.NET MVC здається зосередженими навколо поглядів, які є одним з найбільш "необов'язкових" та модульних бітів в архітектурі. NVelocity , NHaml , Spark , XSLT та інші двигуни перегляду можна легко замінити (і з кожним випуском це стає простіше). Багато з них мають набагато більш стислий синтаксис для логіки презентації та форматування, в той час як все ще надають повний контроль над випромінюваним HTML.

Крім того, майже кожна критика зводиться до позначення <%%> у видах за замовчуванням та до того, наскільки це "потворно". Ця думка часто вкорінюється у використанні підходу WebForms, який просто переміщує більшість класичних неподобств ASP у файл із кодом.

Навіть не роблячи «неправильно» кодування, у вас є такі речі, як OnItemDataBound в Repeaters, що настільки ж естетично некрасиво, хоч інакше, ніж «суп з тегами». Цикл foreach може бути набагато простішим для читання навіть при змінному вбудовуванні у висновок цього циклу, особливо якщо ви прийшли до MVC з інших технологій, які не є ASP.NET. Google-фу знадобиться набагато менше, щоб зрозуміти цикл foreach, ніж зрозуміти, що спосіб зміни цього поля у вашому ретрансляторі - це возитися з OnItemDataBound (і гніздо щура перевіряти, чи це правильний елемент, який потрібно змінити.

Найбільшою проблемою з "спагетті", орієнтованим на теги ASP, було більше про те, щоб підкреслити такі речі, як з'єднання бази даних прямо між HTML.

Те, що це трапилося, використовуючи <%%> - це лише кореляція із характером спагетті класичного ASP, а не причиною. Якщо ви зберігаєте логіку перегляду в HTML / CSS / Javascript і мінімальній логіці, необхідній для презентації , решта - це синтаксис.

Порівнюючи заданий біт функціональності з WebForms, переконайтеся, що включите всі C-файли, створені дизайнером, C і кодом C #, а також код .aspx, щоб переконатися, що рішення MVC насправді не набагато простіше .

У поєднанні з розумним використанням часткових поглядів для повторюваних бітів логіки презентації, це дійсно може бути приємним і елегантним.

Особисто я хочу, щоб більша частина змісту раннього підручника була зосереджена більше на цьому кінці речей, ніж майже виключно на тестовому керуванні, інверсії контролю тощо. Хоча ці інші речі - це те, чому заперечують експерти, хлопці в окопах швидше заперечити проти "супу з тегів".

Незалежно, це платформа, яка все ще знаходиться в бета-версії. Незважаючи на це, розробники WAY отримують більше розгортань, а розробники, що не належать Microsoft, будують з ним фактичні речі, ніж більшість Microsoft-бета-технологій. Таким чином, гудіння має тенденцію до того, що здається, що він знаходиться далі, ніж інфраструктура навколо нього (документація, інструкції та ін.). Це справжнє використання у цей момент просто посилює цей ефект.

<% 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>
<% } %>

Ви можете зробити ще одну публікацію із запитанням, як це зробити, не включаючи вбудований CSS.

ПРИМІТКА: ViewData.Model стає Model у наступному випуску.

І за допомогою контролю користувачів це стане

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

де PagerData ініціалізується через анонімний конструктор в обробці дій.

редагувати: мені цікаво, як виглядала б ваша реалізація WebForm для цієї проблеми.

Я не впевнений, в який момент люди перестали дбати про свій код.

HTML - це найпопулярніший показ вашої роботи. Є багато розробників, які використовують блокнот, блокнот ++ та інші текстові редактори для створення багатьох веб-сайтів.

MVC полягає у поверненні контролю від веб-форм, роботі в умовах без громадянства та реалізації схеми дизайну контролера Model View без усієї додаткової роботи, яка зазвичай відбувається при впровадженні цього шаблону.

Якщо ви хочете контролю, очищення коду та використання шаблонів дизайну MVC, це для вас, якщо вам не подобається працювати з розміткою, не хвилюйтеся, як неправильно отримана розмітка, тоді використовуйте веб-форми ASP.Net.

Якщо вам це не подобається, ви, безумовно, будете робити стільки ж роботи в розмітці.

EDIT Я також повинен зазначити, що Web Forms та MVC мають своє місце, я жодним чином не заявляв, що одна краща за іншу, лише що кожен MVC має силу відновити контроль над розміткою.

Я думаю, ти пропускаєш деякі речі. По-перше, немає потреби в Response.Write, ви можете використовувати <%= %>теги. По-друге, ви можете написати власні розширення HtmlHelper, щоб робити звичайні дії. По-третє, трохи допомагає форматування. По-четверте, все це, ймовірно, застряє в контролі користувача, який розподіляється між декількома різними поглядами, і, таким чином, загальна оцінка в головному вікні є більш чистою.

Я дозволю вам, що надбавка все ще не така акуратна, як хотілося б, але її можна було б значно усунути за допомогою деяких тимчасових змінних.

Тепер це не так вже й погано, і було б ще краще, якби я не мав його форматувати для 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>

  <% } %>

Велика справа з MVC полягає в тому, що це концептуальна основа, яка існує вже давно, і вона зарекомендувала себе як продуктивний, потужний спосіб побудови як веб-додатків, так і додатків робочих станцій, які масштабуються горизонтально і вертикально. Він прямує назад до Альта та Малого розмови. Microsoft запізнюється на вечірку. Те, що ми маємо зараз з ASP.NET MVC, є справді примітивним, тому що так багато можливостей зробити; але чорт, вони швидко і люто виливають нові випуски.

Яка велика справа з Рубі на Рейлах? Рейки MVC. Розробники здійснювали конверсію, оскільки, усно в уста, програмісти стали способом бути продуктивними.

Це величезна справа; MVC та неявна підтримка jQuery є переломними для Microsoft, яка сприймає, що нейтральна платформа є критичною. І що тут нейтрально, це те, що на відміну від Web Forms, Microsoft не може вас концептуально зафіксувати. Ви можете взяти весь свій C # код і повторно доповнити іншою мовою (скажімо, PHP або java - ви його називаєте), оскільки це портативна концепція MVC, а не сам код. (І подумайте, наскільки величезним є той факт, що ви можете сприймати дизайн і реалізовувати його як додаток для робочої станції з невеликою зміною коду і без змін дизайну. Спробуйте це за допомогою веб-форм.)

Microsoft вирішила, що Web Forms не буде наступним VB6.

Будь ласка, подивіться на пост Роб Конери, який я кажу, я просто скажу це: вам слід навчитися MVC

Дві основні переваги рамки ASP.NET MVC перед веб-формами:

1. Testability - користувальницький інтерфейс та події у веб-формах поруч із неможливо перевірити. Завдяки ASP.NET MVC, тестування блоків тестування блоків та їх перегляд легко. Це пов'язано з вартістю передових витрат на розробку, але дослідження показали, що це окупається в довгостроковій перспективі, коли настає час переробляти та підтримувати додаток.
2. Кращий контроль над виведеним HTML - Ви заявляєте, що вам не байдуже наданий HTML, оскільки ніхто не дивиться на нього. Це поважна скарга, якщо це було єдиною причиною правильного форматування HTML. Існує чимало причин, які хочуть правильно відформатованого HTML, включаючи: SEO, можливість частіше використовувати селектори id (у css та javascript), менші розміри сторінок через відсутність візуалізації та смішно довгі ідентифікатори (ctl00_etcetcetc).

Тепер ці причини насправді не роблять ASP.NET MVC кращим чи гіршим, ніж веб-форми, чорно-білим. ASP.NET MVC має свої сильні та слабкі сторони, як і веб-форми. Однак більшість скарг на ASP.NET MVC, мабуть, випливає з недостатнього розуміння того, як його використовувати, а не від фактичних недоліків у рамках. Причина, по якій ваш код не вважає себе правильною або виглядає правильно, може бути тому, що у вас є кілька років досвіду роботи з веб-формами під вашим поясом і лише 1-2 місяці досвіду ASP.NET MVC.

Проблема тут не стільки в тому, що ASP.NET MVC хитається або смокче, це те, що він новий і існує дуже мало домовленостей щодо правильного його використання. ASP.NET MVC пропонує набагато більш тонкий контроль над тим, що відбувається у вашій програмі. Це може зробити певні завдання легшими або складнішими залежно від того, як ви підходите до них.

Гей, я також намагався перейти на MVC. Я абсолютно не прихильник класичного ASP, і MVC-рендерінг мені дуже нагадує ті дні. Однак чим більше я використовую MVC, тим більше він росте на мені. Я хлопець із веб-форм (як багато) і останні кілька років провів звикання до роботи з мережею даних тощо. З MVC, який забирають. Класи HTML Helper - це відповідь.

Зовсім недавно я провів 2 дні, намагаючись зрозуміти найкращий спосіб додавання пейджингу до "сітки" в MVC. Тепер, за допомогою веб-форм, я міг би це швидко вибити. Але я скажу це ... як тільки я створив класи для помічників під час пейджингу для MVC, це стало надзвичайно простим. Мені навіть простіше, ніж веб-форми.

Зважаючи на це, я думаю, що MVC буде набагато приємнішим для розробників, коли там буде послідовний набір HTML Helpers. Думаю, ми найближчим часом побачимо, що в Інтернеті з’явиться багато HTML-допоміжних класів.

Це смішно, тому що це я сказав, коли вперше побачив веб-форми.

Я визнаю, що ще не отримую MpC asp.net. Я намагаюся використовувати це в побічному проекті, який я роблю, але це відбувається досить повільно.

Крім того, що не в змозі робити те, що було так просто зробити в веб-формах, я помічаю суп з тегами. Насправді, схоже, зробити крок назад з цієї точки зору. Я продовжую сподіватися, що, коли я навчаюсь, це покращиться

Поки що я помітив, що головна причина використовувати MVC - це отримати повний контроль над вашим HTML. Я також читав, що asp.net MVC може обслуговувати більше сторінок швидше, ніж веб-форми, і, ймовірно, пов’язаний з цим, розмір окремих сторінок менший, ніж середній розмір сторінки веб-форм.

Мені справді все одно, як виглядає мій HTML, якщо він працює в основних браузерах, але мені все одно, наскільки швидко завантажуються мої сторінки та яка пропускна здатність вони займають.

Хоча я повністю згоден з тим, що це некрасива розмітка, я думаю, що використовувати синтаксис некрасивого перегляду для списання ASP.NET MVC в цілому нечесно. Синтаксис перегляду привернув найменше уваги з боку Microsoft, і я сподіваюся, що незабаром щось буде зроблено.

Інші відповіді обговорювали переваги MVC в цілому, тому я зупинюсь на синтаксисі перегляду:

Заохочення до використання Html.ActionLink та інших методів, що генерують HTML - це крок у неправильному напрямку. Це присмаки керування сервером, і, на мій погляд, вирішує проблему, яка не існує. Якщо ми збираємось генерувати теги з коду, то навіщо взагалі турбувати використання HTML? Ми можемо просто використовувати DOM або якусь іншу модель і створювати вміст у контролері. Гаразд, це звучить погано, чи не так? О так, розділення проблем, тому ми маємо точку зору.

Я думаю, що правильний напрямок - зробити синтаксис перегляду максимально схожим на HTML. Пам’ятайте, що добре розроблений MVC повинен не тільки давати вам відокремлення коду від контенту, він повинен дозволяти вам впорядкувати ваше виробництво шляхом залучення людей, які знають майстер роботи над переглядами (навіть якщо вони не знають ASP.NET), а потім пізніше, як розробник, ви можете вступити і зробити макет перегляду насправді динамічним. Це можна зробити лише в тому випадку, якщо синтаксис перегляду дуже схожий на HTML, так що люди в макеті можуть використовувати DreamWeaver або будь-який інший популярний інструмент компонування. Можливо, ви будуєте десятки сайтів одночасно, і вам потрібно таким чином масштабувати ефективність виробництва. Дозвольте навести приклад того, як я міг бачити "мову" перегляду:

<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;" />

Це має ряд переваг:

• виглядає краще
• більш стислий
• відсутня стильна зміна контексту між HTML та тегами <%%>
• прості для розуміння ключові слова, які не є зрозумілими (навіть непрограміст може це зробити - добре для паралелізації)
• якомога більше логіки повернулося назад у контролер (або модель)
• відсутність генерованого HTML - знову ж таки, це дуже полегшує, коли хтось може зайти і знати, куди щось стилювати, без того, щоб возитися з Html. методи
• у коді є зразок тексту, який відображається, коли ви завантажуєте подання як звичайний HTML у веб-переглядачі (знову-таки, добре для людей з компонуванням)

Отже, що саме робить цей синтаксис?

mvc: inner = "" - все, що є в лапках, оцінюється, а внутрішній HTML тегу заміняється на результуючу рядок. (Наш зразок тексту замінюється)

mvc: external = "" - все, що є в лапках, оцінюється, і зовнішній HTML тегу заміняється на результуючу рядок. (Знову зразок тексту замінюється.)

{} - це використовується для вставлення виводу всередину атрибутів, аналогічно <% =%>

mvc: if = "" - insde qoutes - булевий вираз, який слід евалювати. Після закриття тегу if закривається тег HTML.

mvc: інше

mcv: elseif = "" - ...

mvc: передм

Тепер я можу тут говорити лише для себе:

ІМО, якщо ви твердий (що завгодно), то конверсія не для вас. Якщо ви любите WebForms, це тому, що ви можете досягти того, що вам потрібно, і це теж є метою будь-якого.

Веб-форми добре справляються з тим, щоб абстрагувати HTML від розробника . Якщо це ваша мета, дотримуйтесь веб-форм. У вас є чудова функція "натискання та перетягування", яка зробила розробку робочого столу такою, якою є сьогодні. Є багато включених елементів управління (плюс безліч сторонніх контролів), які можуть спричинити різні функціональні можливості. Ви можете перетягнути "сітку", яка безпосередньо пов'язана з DataSource із вашої бази даних; він поставляється із вбудованим встроенним редагуванням, пейджингом тощо.

На даний момент ASP.NET MVC дуже обмежений з точки зору управління сторонніми сторонами. Отож, знову ж таки, якщо вам подобається швидка розробка програм, де для вас підключено багато функціональних можливостей, вам не слід намагатися конвертувати.

З урахуванням всього цього ASP.NET світить: - TDD. Код не перевіряється, сказав Nuff.

• Поділ проблем. Це є основою моделі MVC. Я цілком усвідомлюю, що ви можете це зробити у веб-формах. Однак мені подобається нав'язана структура. У веб-формах було занадто легко поєднувати дизайн та логіку. ASP.NET MVC полегшує роботу різних членів команди над різними розділами програми.

• Прибуття з іншого місця: Моє тло CakePHP та Ruby on Rails. Отже, зрозуміло, де криється моя упередженість. Це просто про те, що вам подобається.

• Крива навчання: розширення на останню точку; Я ненавидів ідею "шаблону" змінити функціональність різних елементів. Мені не сподобалося, що багато проекту було виконано в коді за файлом. Це було ще одне, чому слід навчитися, коли я вже був глибоко знайомий з HTML та CSS. Якщо я хочу зробити щось у "елементі" на сторінці, я вставляю "div" або "span", ляпаю ідентифікатор на ньому і виходжу. У веб-формах мені доведеться вивчити, як це зробити.

• Сучасний стан веб-дизайну "Бібліотеки Javascript, такі як jQuery, стають все звичнішими. Те, як Web Forms керує вашими ідентифікаторами, просто ускладнює реалізацію (поза Visual Studio).

• Більше розділення (дизайн): Оскільки велика кількість дизайну пов'язана з вашими елементами управління, зовнішньому дизайнеру (без веб-форм) буде дуже важко працювати над проектом Web Forms. Веб-форми були побудовані для того, щоб бути кінцевим і бути всім.

Знову-таки, значна частина цих причин випливає з мого незнайомства з веб-формами. Проект Web Forms (якщо він розроблений правильно) може мати "більшість" переваг ASP.NET MVC. Але це застереження: "Якщо правильно розроблено". І це просто те, що я не знаю, як зробити у веб-формах.

Якщо ви робите зоряну роботу в веб-формах, ви ефективні, і вона працює для вас, саме там вам слід залишитися.

В основному, зробіть швидкий огляд обох (спробуйте знайти неупереджене джерело [удача]) зі списком плюсів і мінусів, оцініть, який з них відповідає вашим цілям, і виберіть на основі цього.

Підсумок, виберіть шлях найменшого опору та максимальну користь для досягнення своїх цілей. Веб-форми - це дуже зріла рамка, яка покращиться лише в майбутньому. ASP.NET MVC - просто інша альтернатива (залучити Ruby on Rails та розробників CakePHP, таких як я: P)

JSP-програми Java EE виглядали так, коли вони були вперше запропоновані - некрасивий код сценарію.

Потім вони запропонували бібліотеки тегів, щоб зробити їх більше HTML-тегами. Проблема полягала в тому, що кожен міг написати бібліотеку тегів. Деякі результати були катастрофічними, оскільки люди вкладали багато логіки (і навіть стилю) у бібліотеки тегів, які генерували HTML.

Я думаю, що найкраще рішення - стандартна бібліотека тегів JSP (JSTL). Це "стандарт", HTML-тег-ish і допомагає запобігти людям розміщувати логіку на сторінках.

Додатковою перевагою є те, що він зберігає цю лінію розмежування між веб-дизайнерами та розробниками. Хороші сайти, які я бачу, розроблені людьми з естетичним почуттям та дизайном для зручності використання. Вони викладають сторінки та CSS і передають їх розробникам, які додають у динамічні біти даних. Виступаючи як розробник, якому не вистачає цих подарунків, я думаю, що ми віддаємо щось важливе, коли ми просимо розробників написати веб-сторінки від супу до горіхів. Flex та Silverlight будуть страждати від тієї ж проблеми, оскільки навряд чи дизайнери добре знають JavaScript та AJAX.

Якщо у .NET був шлях, схожий на JSTL, я б радив їх вивчити.

Я просто подумав, що я поділюсь тим, як виглядає цей зразок із новим блискучим двигуном перегляду Razor, який за замовчуванням починаючи з 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>
}

Якась проблема з цим?
Крім того, ви не повинні фактично вбудовувати свої стилі CSS, чи не так? І чому ви перевіряєте наявність недійсності в трьох місцях, а не лише в двох? Додатковий divрідко болить. Ось як я це зробив:

<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>

Я не можу говорити безпосередньо з проектом ASP.NET MVC, але, як правило, рамки MVC стали домінуючими в розробці веб- додатків, оскільки

1. Вони пропонують формальне розмежування між операціями з базою даних, "бізнес-логіка" та презентацією

2. Вони пропонують достатню гнучкість у перегляді, щоб дозволити розробникам налаштувати свій HTML / CSS / Javascript для роботи в декількох браузерах та майбутніх версіях цих браузерів.

Саме цей останній шматочок є найважливішим. З веб-формами та подібними технологіями ви покладаєтесь на свого постачальника, щоб написати свій HTML / CSS / Javascript для вас. Це потужний матеріал, але ви не маєте гарантії, що поточна версія Webforms буде працювати з веб-браузерами наступного покоління.

У цьому сила погляду. Ви отримуєте повний контроль над HTML програми. Мінус - ти повинні бути досить дисциплінованими, щоб мінімізувати логіку ваших поглядів, а код шаблону - максимально простий.

Отже, це компроміс. Якщо веб-форми працюють для вас, а MVC - ні, продовжуйте використовувати веб-форми

Більшість моїх розчарувань у цьому полягає лише в тому, що я не знаю, як все робити "правильно". Оскільки він був випущений як попередній перегляд, у нас було все мало часу, щоб подивитися на речі, але вони змінилися зовсім небагато. Спочатку я був дуже розчарований, але рамки здаються досить працездатними, щоб я міг досить швидко створювати надзвичайно складні інтерфейси (читати: Javascript). Я розумію, що ви можете це зробити за допомогою веб-форм, як я це робив раніше, але це було величезним болем у задці, намагаючись зробити все, щоб правильно відобразити. Багато разів я б в кінцевому підсумку використовував ретранслятор для контролю точного виходу, і в кінцевому підсумку було б багато спалаху спагетті, який у вас є і вище.

Намагаючись не мати однакового безладу, я використовував комбінацію з доменом, службовими шарами та dto, щоб перенести на представлення. Помістіть це разом із іскрою, двигуном огляду, і це вийде справді приємним. Налаштування потребує трохи, але як тільки ви продовжите це, я побачив великий крок до складності моїх програм візуально, але це так смердюче просто зробити код розумним.

Я б, мабуть, не робив це саме так, але ось ваш приклад:

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

Це досить ремонтопридатне, пробне і смачненьке в моєму кодовому супі.

Винос полягає в тому, що чистий код справді можливий, але це великий зміна дупи від того, як ми займалися. Я не думаю, що все ще це похизує. Я знаю, що я все ще з’ясовую це ...

Нещодавно опублікована книга Стіва Сандерсона "Pro ASP.NET MVC" [1] [2] від Apress пропонує ще одну альтернативу - створення користувацького розширення HtmlHelper. Його зразок (з Розділу 4 на стор. 110) використовує приклад підключеного списку, але його можна легко адаптувати під вашу ситуацію.

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();
}

Ви б назвали це на ваш погляд з кодом приблизно такого:

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

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

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

Я сподівався побачити допис від Філа Хакка, але його тут не було, тому я просто вирізав і вставив його з http://blog.wekeroad.com/blog/i-spose-ill-just-say-it-you-should -learn-mvc / в розділі коментарів

Зламаний - 23 квітня 2009 р. - Роб, ти бунт! :) Мені здається смішним, коли люди пишуть код спагетті в MVC, а потім кажуть "дивись! Спагетті!" Гей, я можу написати і код спагетті у веб-формах! Я можу записати це в рейли, PHP, Java, Javascript, але не в Lisp. Але тільки тому, що я поки не можу нічого написати на Ліспі. А коли я пишу код спагетті, я не дивлюсь на свою тарілку, похмуро очікуючи побачити макарони. Справа, яку люди часто зазначають, порівнюючи її з класичною ASP, полягає в тому, що з класичними ASP люди, як правило, змішують проблеми. Сторінки матимуть логіку перегляду з керуванням введеннями користувачів, змішаними з кодом моделі та бізнес-логікою, всі змішані в одну. Ось про що спагетті йшлося! Змішування стосується всіх в одному великому безладі. З ASP.NET MVC, якщо ви слідуєте шаблону, ви рідше це зробите. Так, у вас все ще може бути трохи коду, але, сподіваємось, це все код перегляду. Шаблон рекомендує вам не вводити туди свій код взаємодії з користувачем. Покладіть його в контролер. Покладіть свій модельний код у модельний клас. Там. Ніяких спагетті. Зараз це O-Toro Sushi. :)

Я також; Я б витратив свій час на Silverlight, а не на ASP.NET MVC. Я спробував MVC 1.0 і переглянув останню версію 2.0 Beta 1 кілька днів тому.

Я (не можу) відчути, що наскільки ASP.NET MVC кращий, ніж веб-форма. Місце продажу MVC:

1. Блок (тест)
   
2. Розділіть дизайн (вид) та логіку (контролер + модель)
   
3. Немає огляду та кращого керування ідентифікатором елементів
   
4. RESTful URL та багато іншого ...

Але веб-форма, використовуючи код-позаду. Тема, Шкіра та Ресурс вже ідеально підходять для розділення дизайну та логіки.

Viewstate: управління ідентифікатором клієнта надходить на ASP.NET 4.0. Мене турбують лише тести на одиницю, але одиничні тести є недостатньою причиною, щоб перейти до веб-форми ASP.NET MVC.

Можливо, я можу сказати: ASP.NET MVC непоганий, але веб-форми вже достатньо.

Я використовую MVC з тих пір, як вийшов Preview 3, і поки він все ще сильно зростає, він трохи допомагає в області розвитку команди. Спробуйте, щоб троє людей працювали на одній сторінці веб-форм, і тоді ви зрозумієте концепцію удару головою об стіну. Я можу співпрацювати з розробником, який розуміє елементи дизайну на сторінці перегляду та нашим резидентом богом Linq над тим, щоб модель працювала, поки я все склав у контролер. Мені ніколи не вдалося розвинутись у царині, де розділення проблем було так легко досягти.

Найбільша точка продажу ASP.Net MVC - StackOverflow працює на стеку MVC.

При цьому, ваш код настільки гарніший, ніж те, що я зазвичай роблю зі сторінкою перегляду. Крім того, один із хлопців, з якими я працюю, працює над тим, щоб перетворити помічник HTML у бібліотеку тегів. Замість <% = Html.RandomFunctionHere ()%> це працює так

<hh: випадкова функція />

Я просто сподіваюсь, що команда MVC в якийсь момент обійдеться до неї, бо я впевнена, що вони краще зробили б це.

Використовуйте шаблон фасаду, щоб обернути всю логіку для всіх даних, які потрібно відобразити, а потім використовувати їх як загальний на ваш погляд, а потім .... не більше коду спагетті. http://en.wikipedia.org/wiki/Design_pattern_(computer_science)

Якщо вам потрібна додаткова допомога, cgardner2020@gmail.com

Реалізація ASP.NET MVC жахлива. Виріб звичайно смокче. Я бачив кілька демонстрацій цього матеріалу і мені соромно за MSFT ... Я впевнений, що хлопці, які написали це, розумніші за мене, але це майже так, як ніби вони не знають, що таке Model-View-Controller .

Єдині, кого я знаю, які намагаються впровадити MVC - це люди, які люблять спробувати нові речі від MSFT. У демонстрації, яку я бачив, ведучий мав вибачливий тон ...

Я великий фанат MSFT, але мушу сказати, що я не бачу причин заважати їх впровадженню MVC. Або використовуйте веб-форми або використовуйте jquery для веб-розробки, не вибирайте цю гидоту.

Редагувати:

Метою архітектурного дизайну Model-View-Controller є відокремлення вашого домену від презентації від бізнес-правил. Я успішно використовував цю схему у кожному реалізованому нами проекті веб-форм. Продукт ASP.NET MVC не піддається фактичній схемі архітектурного дизайну.