Как я могу избежать суп сук с помощью MVC?

Question

Я читал это в моих поисках, чтобы оправдать MVC над не-MVC, как обычный старым PHP (не использовать MVC, даже классические осины могут быть использованы, хотя и болезненно):

http://www.codinghorror.com/blog/2008/07/web-development-as-tag-soup.html

И я не могу найти ответ. Я думаю, что неизбежно получить суп с тегами. Да, я знаю, что MVC разделяет модель и контроллер, но когда вы добираетесь до представления, все просто отвратительно. Я могу читать испускаемый html так же хорошо, как лучше, чем суп для тегов.

Я не буду использовать модульное тестирование, поэтому это не так важно. Я не уверен, как я могу избежать уродливого взгляда, теперь важно, как я его утихомию mvc или просто испускаю html.

Я не вижу, чтобы было проще поддерживать представление со всем странным кодированием (и это код), чем с использованием response.write "<table>".

пример: Dealing with ASP.NET MVC "tag soup"

Ответ на Арнис (не в обиду ему или кому-либо еще), фиксирует ужасный код в вопросе, но мне, что по-прежнему выглядит плохо или, по крайней мере, не то, что я ожидал. Для меня эти угловые кронштейны также могут быть <% %> или <?php ?>.

Мне нравятся такие вещи, как codeigniter, и это действительно самый чистый, который я видел, но это все еще не то, что я ожидаю. Я думаю, я надеялся, что в MVC присутствует какая-то магия, которая сделала все красивым. По-видимому, если кто-то действительно не очень осторожен, там не лучше, чем с классическим asp, поскольку это касается взгляда.

Это в основном о представлении. Не о том, какой язык лучше для того, кто или кто движок шаблонов является самым большим (все они имеют одинаковые тенденции смешивания разметки).

Верьте мне. I хочу, чтобы MVC работал с моими со-разработчиками, поэтому я не отказываюсь от него как парадигмы вообще. Я не могу заставить их согласиться на что-то только потому, что все делают это или что-то в этом роде.

Благодарим за любые комментарии. Я должен быть в состоянии оправдать эти вещи, и, хотя я понимаю, что MVC и то, что я получаю, взгляд делает многое из этого, похоже, большой тратой времени.

Редактировать: Все, кажется, ориентировано на конкретную структуру вместо плана. Я вижу некоторое понимание, но, в конце концов, похоже, что нет никакой дисциплины. Спасибо всем за ваши ответы.

Answer 1

Там и обратно. Опять и опять. Сырой HTML. Dreamwearver. ASP. MS Word. ASP.NET, MVC.NET. Мы, кажется, можем поразить любой конец спектра, но в середине нет сладкого пятна.

В конечном счете, возможно, самое большее, что мы можем надеяться сказать, «хорошо, по крайней мере, все безумие изолировано в представлении». Я говорю «надежда», потому что по моему опыту гораздо проще сказать «объектно-ориентированный», чем делать объектно-ориентированные со всем программным принципом добродетели, которые подразумевает OO.

В конечном счете суп-суп не является проблемой. Это абсолютно не проблема в контексте MVC. Проблема в кодировании - проблема. Части MVC, слитые вместе, как сиамские триплеты, наглядно демонстрирующие некомпетентность в разработке программного обеспечения и принципах кодирования, безусловно, являются большим преступлением.

Структура MVC, как Ruby on Rails или MVC.NET поможет повысить эффективность кодирования при кодировании в парадигме MVC; это не сделает вас быстрее кода как такового. И это, безусловно, не помешает кошмару кодового обслуживания, если вы не знаете, какого черта вы делаете.

Answer 2

1. Используйте двигатель просмотра razr (Мое предпочтение, я думаю, он выглядит аккуратно). response.write "<table>" достаточно легко написать. Но делаете ли вы это в файле/классе, который ТОЛЬКО контролирует представление и может быть легко заменен или изменен, не касаясь какой-либо логики обслуживания? Это подводит меня к # 2.
2. Обсудите разделение проблем с вашей группой и определите, где живет каждая часть логики. Где находятся контрольные точки зависимостей, все ли ваша логика сгруппированы в DLL, которые не имеют представления о просмотрах/контроллерах? Решите от начала и запишите его где-нибудь.
3. Держите взгляды как виды!
4. Не делайте ничего на виду!
5. Как только вы находитесь на виду, которое вы просто просматриваете!
6. Я упомянул, что взгляды - это только то, что?

Я не жалуюсь никому на использование MVP или любой другой парадигмы. Но если вы хотите попробовать MVC, сделайте это правильно, и вы обнаружите, что рефакторинг и поддержание кода намного проще.

мои 2cents

Answer 3

Преимущества просмотра слоя над тегом супом является то, что вид слой должен изолировать плохую логику от плохих данных, что делает первопричину проще отследить. Это не произойдет автоматически, его нужно испечь в кодовых ограничениях представления. Лучший подход, который я видел в отношении взглядов HTML с использованием MVC следующий (из Tony Marston):

• код, который преобразует данные в HTML логика отображения.
• Код, который создает или получает данные, которые впоследствии преобразуются в HTML, не является логикой отображения.

Зная, что это половина сражения, последовательная реализация - это другая. С большой силой приходит большая ответственность, поэтому использование ограниченного набора команд помогает обеспечить более чистый код. Минимальные утверждения будут печататься и включаться. Связывание и привязка данных для генерации таблиц, списков или форм могут обрабатываться библиотеками JavaScript или XSLT. Переменное назначение, условная логика и манипуляция строками могут выполняться в локальном или глобальном включении. Все, что может быть обработано моделью или контроллером.

Answer 4

Посмотрите на использование двигателя Razor, который входит в комплект поставки MVC 3. Также попробуйте сохранить всю свою логику в классе Контроллер и построить Модель на основе того, что отображается в Просмотр.

• Бритва является одним из очевидных способов избежать тегов супа, поскольку нет никакой необходимости в каких-либо <% и %> тегов - просто @ перед кодом и вид двигатель работает где C# заканчивается и HTML начинается.

  <span class="name">@Model.Name</span> 
  

  Даже петля и если инструкции по-прежнему выглядеть сексуально в .cshtml файл с Razor и волшебных @ характера.

  @if(shouldDisplayDiv) { 
      <div id="mydiv">Div is displayed!</div> 
  } 
  
  
  @foreach(User user in Model.Friends) { 
      <a href="@user.Url"><img src="@user.ImageUrl" title="@user.Name" /></a> 
  } 
  

  Бритва также обрабатывает кодирование HTML для вас по умолчанию, так что ваша точка зрения не будет полна Html.Encode звонков. (Примечание: если вам нужно вывести HTML, вы можете использовать вспомогательный метод Html.Raw).

• Положив свою логику в контроллер будет идеально устранить необходимость больших блоков кода в представлении. Попытайтесь, чтобы объекты модели содержали все динамические данные для представления, точно так же, как они будут отображаться в представлении. Цель не иметь любой Код на C# в вашем представлении вообще (бессмысленно, но если это цель, посмотрите, как близко вы можете добраться до него!).

• Частичный вид может хорошо отделить различные части вашего зрения (но старайтесь не использовать их слишком много). Вы также можете передать другой объект модели на каждый частичный вид, который, как мне кажется, может быть полезен для некоторых больших циклов или что-то вроде flair.

• HTML Помощники также очень полезны (спасибо subkamran). Здесь есть аналогичная концепция для частичных представлений, упомянутых выше, но HtmlHelpers несколько отличаются, потому что вы указываете параметры метода (и их типы), в отличие от частичных представлений, которые вы можете передать одному объекту модели. Вот good example of how to implement them. Опять же, они могут выглядеть очень аккуратно в вашем коде cshtml.

  <div class="specialdiv">@Html.SomeMethod(Model, "String", 5)</div> 
  

• стороне клиента MVC это еще один вариант, и сильное предложение, если вы разрабатываете AJAX-тяжелых веб-приложений. Следуя логике в контроллере, вы должны использовать структуру MVC на стороне клиента, такую ​​как Backbone.js, в шаблон HTML в порядке и использовать jQuery .ajax() для разговора с вашим контроллером. Это отличная практика для разделения вашего слоя презентации, оставляя вас с красивой разметкой View!

Я придерживаюсь этих небольших рекомендаций, и это работает как очарование для меня. Приятная, чистая разметка HTML со случайным персонажем @. Очень прост в обслуживании (ну, по крайней мере, взгляды есть!).

EDIT: Пожалуйста, обратите внимание, что все эти пункты включены в ASP.NET MVC 3 и все «лучшие практики» далеко, как Microsoft обеспокоены. Нет необходимости устанавливать какие-либо дополнительные рамки, плагины или дополнения, чтобы придерживаться этих рекомендаций.

Answer 5

Не делайте расчетов в вашем шаблоне кода.

Взгляните на то, что разрешено в Django: https://docs.djangoproject.com/en/1.3/topics/templates/

Нет арифметику. Отсутствие параметров для методов. Никаких определений какого-либо рода (кроме как в циклах).Это заставляет вас делать почти все в методах представления и передавать любые требуемые объекты и списки, что сохраняет его в чистоте.

Answer 6

Существует причина, по которой MVC набирает силу. Хотя верно, что есть несколько тегов, добавленных в представление, гораздо проще, если логика правильно обрабатывается в контроллере, где он должен принадлежать.

Также важно понять, что такое MVC: http://en.wikipedia.org/wiki/Model-view-controller. Преимущества, которые вы получаете от него, - это более чистое разделение и простая замена.

Рассмотрите это. У вас есть клиент, который хочет, чтобы вы записали приложение, которое поддерживает как традиционные браузеры, так и мобильные браузеры. С шаблоном MVC очень легко заставить контроллер определить платформу и изменить отображаемое представление. Если все сделано правильно, замена одного представления для другого должна быть очень простым процессом.

У меня есть 7-летний опыт написания приложения в ASP.NET-формах. Как только я переключился на MVC и начал понимать MVC, я понял, что никогда не вернусь. Представления чище, отладка проще и логика более очевидна. Последнее приложение, которое я написал, использует MVC и jQuery, имеет 3000 пользователей в день и стало образцовым сайтом, для которого теперь все наши сайты написаны.

Наш клиент попросил нас добавить мобильную поддержку на наш сайт. Поскольку мы выбираем MVC в нашей реализации, нам потребовалось 1 неделя, чтобы добавить полную поддержку мобильных устройств. Мы не могли бы так быстро это сделать и использовать код настолько эффективно, если бы сделали это в ASP.NET Forms.

В то время как пример кода от http://www.codinghorror.com/blog/2008/07/web-development-as-tag-soup.html выглядит ужасно, вы когда-нибудь смотрели на ASP.NET GridView? HTML ужасен. Образец, который вы предоставили, также показывает того, кто мог бы сделать некоторую работу, чтобы очистить свои взгляды. Вот сравнение с GridView против MVC с Razor:

GridView:

<asp:datagrid id="voucherGrid" runat="server" CssClass="dg" CellPadding="2" AutoGenerateColumns="False" DataKeyField="cx_nbr" 
     Width="800px" AllowPaging="True" AllowSorting="True" PageSize="20" OnPageIndexChanged="voucherGrid_PageIndexChanged" 
     OnSortCommand="voucherGrid_SortCommand" OnItemDataBound="voucherGrid_ItemDataBound"> 
     <SelectedItemStyle CssClass="dgSelectItem"></SelectedItemStyle> 
     <AlternatingItemStyle CssClass="dgAlternateItem"></AlternatingItemStyle> 
     <ItemStyle CssClass="dgNormalItem"></ItemStyle> 
     <HeaderStyle ForeColor="White" CssClass="dgHeader"></HeaderStyle> 

     <Columns> 
      <asp:TemplateColumn HeaderText="Image"> 
       <ItemStyle HorizontalAlign="Center"></ItemStyle> 
       <ItemTemplate> 
        <asp:HyperLink id="voucherImageLink" Target="_blank" runat="server">Image</asp:HyperLink>            
       </ItemTemplate> 
      </asp:TemplateColumn> 
      <asp:BoundColumn DataField="cx_voucher_nbr" SortExpression="cx_voucher_nbr" HeaderText="Call #"> 
       <ItemStyle HorizontalAlign="Center"></ItemStyle> 
      </asp:BoundColumn> 
      <asp:BoundColumn DataField="cx_pkup_datetime" SortExpression="cx_pkup_datetime" HeaderText="Date" DataFormatString="{0:MM/dd/yyyy}"> 
       <ItemStyle HorizontalAlign="Center"></ItemStyle> 
      </asp:BoundColumn> 
      <asp:BoundColumn DataField="cx_pass_name" SortExpression="cx_pass_name" HeaderText="Passenger"> 
       <ItemStyle Wrap="False"></ItemStyle> 
      </asp:BoundColumn> 
      <asp:BoundColumn DataField="cx_pkup_address" SortExpression="cx_pkup_address" HeaderText="Pick-Up"> 
       <ItemStyle Wrap="False"></ItemStyle> 
      </asp:BoundColumn> 
      <asp:BoundColumn DataField="cx_dest_address" SortExpression="cx_dest_address" HeaderText="Destination"> 
       <ItemStyle Wrap="False"></ItemStyle> 
      </asp:BoundColumn> 
      <asp:BoundColumn DataField="cx_trip_miles" SortExpression="cx_trip_miles" HeaderText="Miles" DataFormatString="{0:N2}"> 
       <ItemStyle HorizontalAlign="Right"></ItemStyle> 
      </asp:BoundColumn> 
      <asp:BoundColumn DataField="cx_pkup_datetime" SortExpression="cx_pkup_datetime" HeaderText="Time" DataFormatString="{0:t}"> 
       <ItemStyle HorizontalAlign="Center"></ItemStyle> 
      </asp:BoundColumn> 
      <asp:BoundColumn DataField="cx_vch_wait_time_amt" SortExpression="cx_vch_wait_time_amt" HeaderText="Wait" DataFormatString="{0:C}"> 
       <ItemStyle HorizontalAlign="Right"></ItemStyle> 
      </asp:BoundColumn> 
      <asp:BoundColumn DataField="cx_vch_other_amt" SortExpression="cx_vch_other_amt" HeaderText="Other" DataFormatString="{0:C}"> 
       <ItemStyle HorizontalAlign="Right"></ItemStyle> 
      </asp:BoundColumn> 
      <asp:BoundColumn DataField="cx_vch_admin_charge_amt" SortExpression="cx_vch_admin_charge_amt" HeaderText="Admin Charge" DataFormatString="{0:C}"> 
       <ItemStyle HorizontalAlign="Right"></ItemStyle> 
      </asp:BoundColumn> 
      <asp:BoundColumn DataField="cx_vch_fare_amt" SortExpression="cx_vch_fare_amt" HeaderText="Rate" DataFormatString="{0:C}"> 
       <ItemStyle HorizontalAlign="Right"></ItemStyle> 
      </asp:BoundColumn> 
     </Columns> 

     <PagerStyle ForeColor="White" CssClass="dgPager" Mode="NumericPages"></PagerStyle> 
    </asp:datagrid> 

Razor:

<table id="voucherGrid" class="dg" style="width: 800px;"> 
    <th class="dgHeader"> 
     <td>Image</td> 
     <td>Call #</td> 
     <td>Date</td> 
     <td>Passenger</td> 
     <td>Pick-Up</td> 
     <td>Destination</td> 
     <td>Miles</td> 
     <td>Time</td> 
     <td>Wait</td> 
     <td>Other</td> 
     <td>Admin Charge</td> 
     <td>Rate</td> 
    </th> 
    @foreach(var voucher in Model.Vouchers) { 
    <tr> 
     <td>@voucher.Image</td> 
     <td>@voucher.CallNum</td> 
     <td>@voucher.Date</td> 
     <td>@voucher.Passenger</td> 
     <td>@voucher.PickUp</td> 
     <td>@voucher.Destination</td> 
     <td>@voucher.Miles</td> 
     <td>@voucher.Time</td> 
     <td>@voucher.Wait</td> 
     <td>@voucher.Other</td> 
     <td>@voucher.AdminCharge</td> 
     <td>@voucher.Rate</td> 
    </tr> 
    } 
</table> 

Вы скажите мне, что выглядит легче понять? Для меня это гораздо чище иметь дело с html-тегами и несколькими дополнительными @ или <% тегами.

Вы также указали, что нет необходимости в модульном тестировании. Я бы пересмотрел эту мысль. Единичное тестирование может быть чрезвычайно полезным при поиске проблем до того, как они произойдут на производственной площадке.

Answer 7

Вы можете использовать GWT, ZK, Vaadin, JSF 2 или что-то, что скрывает HTML. Я не знаю, что вы подразумеваете под MVC. Модель Django/RoR/CakePHP Model-View-Presenter, иногда называемая MVC или реальным MVC. Если вы придерживаетесь MVC, у вас должно быть ТОЛЬКО привязка данных и триггеры событий в вашем коде просмотра.

Я думаю, что это проблема дизайна, а не технология.