Найбільша перевага у використанні ASP.Net MVC та веб-форм

Які є переваги використання одного над іншим?

Основними перевагами ASP.net MVC є:

1. Вмикає повний контроль над виведеним HTML.

2. Забезпечує чітке розділення проблем (SoC).

3. Вмикає розробку тестового керування (TDD) .

4. Проста інтеграція з рамками JavaScript.

5. Слідом за дизайном Інтернету без громадянства.

6. RESTful URL-адреси, які дозволяють SEO.

7. Немає подій ViewState та PostBack

Основною перевагою веб-форми ASP.net є:

1. Він забезпечує розвиток RAD

2. Проста модель розробки для розробників, які виходять з розробки winform.

Веб-форми ASP.NET і MVC - це дві веб-рамки, розроблені Microsoft - вони обидва хороші варіанти. Жодна з веб-рамок не повинна бути замінена іншою, або не планується їх об'єднання в єдину рамку. Постійна підтримка та розробка здійснюються паралельно Майкросоюзом, і жоден з них не буде "відходити".

Кожна з цих веб-рамок має переваги / недоліки - деякі з яких потрібно враховувати при розробці веб-додатку. Веб-додаток можна розробити за допомогою будь-якої технології - це може полегшити розробку конкретного додатка, вибравши одну технологію порівняно з іншою та навпаки.

Веб-форми ASP.NET:

• Розвиток підтримує держава • Створює ілюзію, що веб-додаток знає про те, що робить користувач, подібно до програм Windows. Тобто функціонал "майстра" трохи легше реалізувати. Веб-форми справляють велику роботу, приховуючи від розробника багато такої складності.
• Швидкий розвиток додатків (RAD) • Можливість просто "заскочити" і почати надсилати веб-форми. Цьому заперечують деякі спільноти MVC, але Microsoft їх підштовхує. Зрештою, це зводиться до рівня знань розробника та того, що їм комфортно. Модель веб-форм, мабуть, має меншу криву навчання для менш досвідчених розробників.
• Більша панель інструментів управління • Веб-форми ASP.NET пропонує набагато більшу і надійну панель інструментів (веб-керування), тоді як MVC пропонує більш примітивний набір керувань, спираючись більше на керовані клієнтські елементи управління через jQuery (Javascript).
• Зрілий • Це вже близько 2002 року, і існує велика кількість інформації щодо питань, проблем тощо. Пропонується більше сторонніх контролю - потрібно враховувати наявні набори інструментів.

ASP.NET MVC:

• Розділення проблем (SoC) • З технічної точки зору організація коду в MVC дуже чітка, організована і деталізована, що спрощує (надіюсь) веб-додаток масштабування з точки зору функціональності. Сприяє чудовому дизайну з точки зору розвитку.
• Простіша інтеграція з інструментами на базі клієнта (розширені інструменти для користувальницького інтерфейсу) на базі • Більше, ніж будь-коли, веб-додатки все більше стають настільки ж багатими, як програми, які ви бачите на своїх робочих столах. Завдяки MVC він дає можливість інтегруватися з такими наборами інструментів (такими як jQuery) з більшою легкістю та більш легко, ніж у веб-формах.
• Оптимізація пошукових систем (SEO), зручна / без громадянства • Безкоштовна URL-адреса - більш зручна до пошукових систем (наприклад, mywebapplication.com/users/ 1 - отримання користувача з ідентифікатором 1 проти mywebapplication / користувачів / getuser.aspx (ідентифікатор, переданий у сесії)). Так само, оскільки MVC є без громадянства, це знімає головний біль у користувачів, які породили кілька веб-браузерів з одного вікна (колізійні сеанси). У той же самий спосіб MVC дотримується веб-протоколу без громадянства, а не "бореться" з ним.
• Добре співпрацює з розробниками, яким потрібен високий ступінь контролю • Багато елементів керування у веб-формах ASP.NET автоматично генерують велику частину необробленого HTML, який ви бачите під час надання сторінки. Це може спричинити головний біль у розробників. З MVC він краще піддається повному контролю над тим, що надається, і сюрпризів немає. Ще важливіше - це те, що HTML-форми, як правило, набагато менше, ніж веб-форм, що може прирівнюватися до підвищення продуктивності - що варто серйозно розглянути.
• Тестова розробка (TDD) • За допомогою MVC ви можете легше створювати тести для веб-сторінок. Додатковий рівень тестування забезпечить ще один рівень захисту від несподіваної поведінки.

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

Кожен, хто достатньо старший, щоб запам’ятати класичний ASP, запам'ятає кошмар відкриття сторінки з кодом, змішаним з html та javascript - навіть найменша сторінка була болем, щоб зрозуміти, що, до біса, це робить. Я можу помилитися, і я сподіваюся, що є, але MVC виглядає так, як повертаюся в ті погані старі часи.

Коли ASP.Net прийшов, він був визнаний рятівником, відокремлюючи код від вмісту і дозволяючи веб-дизайнерам створювати html, а кодери працюють над кодом позаду. Якщо ми не хотіли використовувати ViewState, ми його вимкнули. Якщо ми з якихось причин не хотіли використовувати код позаду, ми можемо розмістити наш код всередині html так само, як класичний ASP. Якщо ми не хотіли використовувати PostBack, ми перенаправили на іншу сторінку для обробки. Якщо ми не хотіли використовувати елементи керування ASP.Net, ми використовували стандартні керування html. Ми навіть могли б допитати об’єкт Response, якби не хотіли використовувати ASP.Net runat = "сервер" на наших елементах управління.

Тепер хтось із їхньої великої мудрості (можливо, хтось, хто ніколи не програмував класичний ASP) вирішив, що саме час повернутися до днів змішування коду зі змістом і назвав це "розділенням проблем". Звичайно, ви можете створити більш чистий html, але ви могли б із класичним ASP. Сказати "ви не правильно програмуєте, якщо у вас занадто багато коду всередині вашого перегляду", це як сказати "якщо ви написали добре структурований і коментований код у класичному ASP, це набагато чистіше і краще, ніж ASP.NET"

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

І останнє, але не в останню чергу новий двигун Razor означає, що ще важче відрізнити html та код. Принаймні, ми могли шукати теги відкриття та закриття, тобто <% і%> в ASP, але тепер єдиним вказівкою буде символ @.

Можливо, час перейти на PHP і почекати ще 10 років, щоб хтось знову відокремив код від контенту.

Якщо ви працюєте з іншими розробниками, такими як PHP або JSP (і я гадаю рейки) - вам буде набагато простіше перетворити або співпрацювати на сторінках, тому що у вас не буде всіх тих "бридких" ASP.NET події та управління скрізь.

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

1. Належний AJAX, наприклад, JSONResults не має часткової дурниці після оприбуткування сторінки.
2. немає огляду +1
3. Немає перейменування HTML-ідентифікаторів.
4. Чистий HTML = відсутність процвітання та гідне враження щодо надання XHTML або сторінок, що відповідають стандартам.
5. Більше не створюється JavaScript AXD.

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

Я не бачив жодних переваг у MVC над ASP.Net. 10 років тому Microsoft придумала UIP (User Interface Process) як відповідь на MVC. Це був флоп. Ми зробили великий проект (4 розробники, 2 дизайнери, 1 тестер) з UIP тоді, і це був просто кошмар.

Не просто заскакуйте на прокладку заради Hype. Усі перелічені вище переваги вже доступні в Asp.Net (З більш чудовими налаштуваннями [ Нові функції в Asp.Net 4 ] в Asp.Net 4).

Якщо ваша команда розробників або окрема сім'я розробників з Asp.Net просто дотримуйтесь її і швидко робите красиві продукти, щоб задовольнити своїх клієнтів (хто оплачує ваші робочі години). MVC з'їсть ваш цінний час і дасть ті самі результати, що і Asp.Net :-)

Френсіс Шанахан,

1. Чому ви називаєте часткове післязавантаження "дурницею"? Це головна особливість Ajax і він дуже добре використаний в рамках Atlas та чудових сторонніх контролів, таких як Telerik

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

3. У моделі веб-форми ASP.NET перейменовано лише елементи керування HTML-сервером, а не чисті елементи керування html. Як би це не було, чому ви так переживаєте, якщо перейменування буде зроблено? Я знаю, що ви хочете мати справу з багатьма подіями JavaScript на стороні клієнта, але якщо ви конструюєте веб-сторінки розумно, ви, безумовно, можете отримати всі ідентифікатори, які ви хочете

4. Навіть веб-форми ASP.NET відповідають стандартам XHTML, і я не бачу здуття. Це не є виправданням того, чому нам потрібна схема MVC

5. Знову ж, чому ви турбуєтесь AXD Javascript? Чому це вам шкодить? Це знову не є дійсним обґрунтуванням

Поки що я прихильник розробки додатків за допомогою класичних веб-форм ASP.NET. Наприклад: Якщо ви хочете прив’язати випадаючий список або перегляд сітки, вам потрібно максимум 30 хвилин і не більше 20 рядків коду (мінімум, звичайно). Але у випадку MVC, поговоріть з розробниками, як це болить.

Найбільшим недоліком MVC є те, що ми повертаємося до часів ASP. Пам'ятайте код спагетті для змішування коду сервера та HTML ??? Боже мій, спробуй прочитати сторінку aspx MVC, змішану з тегами javascript, HTML, JQuery, CSS, тегами сервера і що ні .... будь-який орган може відповісти на це питання?

Веб-форми також отримують від більшої зрілості та підтримки від сторонніх постачальників контролю, таких як Telerik.

У веб-формах ви також можете відтворити майже весь html вручну, за винятком кількох тегів, таких як viewstate, eventvalidation тощо), які можна видалити за допомогою PageAdapters. Ніхто не змушує вас використовувати GridView або якесь інше управління на стороні сервера, що має поганий вихід HTML-рендерінгу.

Я б сказав, що найбільша перевага MVC - ШВИДКА!

Далі - вимушена розлука турбот. Але це не забороняє вам вводити цілу логіку BL і DAL всередину Controller / Action! Це просто розділення поглядів, що можна зробити також у веб-формах (наприклад, MVP-шаблон). Багато речей, які люди згадують про mvc, можна зробити у веб-формах, але з деякими додатковими зусиллями.
Основна відмінність полягає в тому, що запит надходить до контролера, а не до перегляду, і ці два шари розділені, не з'єднані через частковий клас, як у веб-формах (aspx + код позаду)

Мої 2 копійки:

• Форми ASP.net чудово підходять для швидкого розвитку додатків та швидкого додавання ділової вартості. Я все ще використовую його для більшості інтранетних додатків.
• MVC чудово підходить для оптимізації пошукових систем, оскільки ви в більшій мірі контролюєте URL-адресу та HTML
• MVC, як правило, створює набагато більш швидку сторінку - відсутність огляду та чистішого HTML = швидкість завантаження
• MVC легко кешувати частини сторінки. -MVC приємно писати: - особиста думка ;-)

MVC дозволяє мати кілька форм на сторінці. Невелика функція, яку я знаю, але вона зручна!

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

Контролер MVC:

    [HttpGet]
    public ActionResult DetailList(ImportDetailSearchModel model)
    {
        Data.ImportDataAccess ida = new Data.ImportDataAccess();
        List<Data.ImportDetailData> data = ida.GetImportDetails(model.FileId, model.FailuresOnly);

        return PartialView("ImportSummaryDetailPartial", data);
    }

Перегляд MVC:

<table class="sortable">
<thead>
    <tr><th>Unique Id</th><th class="left">Error Type</th><th class="left">Field</th><th class="left">Message</th><th class="left">State</th></tr>
</thead>
<tbody>
    @foreach (Data.ImportDetailData detail in Model)
    {
    <tr><th>@detail.UniqueID</th><th class="left">@detail.ErrorType</th><th class="left">@detail.FieldName</th><th class="left">@detail.Message</th><th class="left">@detail.ItemState</th></tr>
    }
</tbody></table>

Наскільки це важко? Немає життєвого циклу сторінки ViewState, немає життєвого циклу BS ... Просто чистий ефективний код.

Я бачу, що єдиними двома перевагами для менших сайтів є: 6) RESTful URL-адреси, які дозволяють SEO. 7) Немає подій ViewState та PostBack (та загальна ефективність)

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

Я чітко бачу перевагу MVC на великих веб-сайтах для багатьох розробників.

Основна перевага, яку я знаходжу, полягає в тому, що вона змушує проект зробити більш тестувальну структуру. Це досить легко можна зробити і з веб-формами (MVP pattern), але вимагає від розробника розуміння цього, багато чого не потрібно.

Вебформи та MVC - обидва життєздатні інструменти, обидві успіхи в різних областях.

Я особисто використовую веб-форми, коли ми в першу чергу розробляємо додатки B2B / LOB. Але ми завжди робимо це за схемою MVP, за допомогою якої ми можемо досягти 95 +% покриття коду для наших тестових одиниць. Це також дозволяє нам автоматизувати тестування на властивості веб-контролів, які визначаються через властивість веб-контролів, наприклад

bool IMyView.IsAdminSectionVisible{
       get{return pnlAdmin.Visible;}
       get{pnlAdmin.Visible=value;}
    }

) Я не думаю, що цей рівень тестування настільки легко досягається в MVC, не ґрунтуючи мою модель.

Ви більше не почуваєтесь погано, коли використовуєте "не після управління" і придумуєте їх, як перенести їх у традиційне середовище asp.net.

Це означає , що сучасні (безкоштовно для використання) управління JavaScript такі це або це або це все можуть бути використані без того підлаштовуватися круглу затичку в квадратний отвір відчувати.

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

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