ASP.NET MVC vs WebForms...

... или кое е онова нещо, което да ме накара да използвам MVC vs WebForms?
За чиф ми е да ползвам MVC?

А, не бе... стой си прост :-)) Никой не те кара!

[линк]

то който му е трябвало, си го е написал до сега, не е чакал МС да го осемени....

Верно като гледам, пълно е с home-made франкенщайнчета...

[линк]

Мазаха 7-8 години по Уебформс и вече е в такъв стейт, че повече не могат да мажат и трябва нещо уж друго да правят. MVC е общо взето имитация на Рейлс.

Ако сега почвам проект бих го писал на MVC, ама предполагам съм от малциноството а пък и предполагам поне половината ми логика ще е Javascript, така че няма да има голямо значение отдолу какво ще е. Даже мога да го направя само Джаваскрипт да вика РЕСТ сървиси отдолу и никакви MVC/УебФормс да няма.

Иначе - на АСП.НЕТ най-големите глупости са ViewState и Page Lifecycle - в някои по-сложни случаи може човек да се побърка кое кога се вика, как кога му се възстановява стейта, етц. MVC пък в момента не виждам какво повече ми дава от това Джаваскрипта да вика сървиси.

Лично мене ме устройва - всяко "развитие" в АСП.НЕТ стека и особено форкване на такива майорни неща като МВЦ означава повече пазар за моите продукти, така че аз съм им свикнал на Майкрософт - вече 8 години им надграждам комерсиално АСП.НЕТ стака и им знам кода наизуст с Рефлектора (кода за генериране на ClientID е уникален, препоръчвам да се види - сигурно пиян индиец го е писал). Живи здрави, да мислят глупости, няма проблеми.

--
One day it will make sense.

Даже мога да го направя само Джаваскрипт да вика РЕСТ сървиси отдолу и никакви MVC/УебФормс да няма

Pure AJAX-а е друго нещо.

Имам впредвид следното.
За какво ми е Controller-Model-View?

ОК, казват че "имаш пълен контрол над аутпута..." дрън-дрън.
Като гледам масово за View-та се използват уеб форми, та в тази връзка за чиф ми е MVC след като с WebForms без използване на сървър контроли и с бизнес логика си е все същото?
Каква е разликата ако самото View си хит-ва бизнес логиката, байндва си данните и си рендва резултата? Та за чиф ми е контролер тука?

В повечето случаи простотата е за предпочитане

ОК, само не разбрах какво повече ти дава лично на теб MVC патерна?
Защо го използваш?
Или май го ползваш само щото тва е модата и щото някой ти е казал, че тва MVC е върха, а?

MVC-то ти е една идея по-бързо от формирте- няма ги тия проклети стейтове. В началото може да ти е терсене кво е модел, вию, контролер, ако до момента не си ползвал друго. Като свикнеш всичко е наред.

Ако днес започвам нов проект определено бих ползвал Ръби - няма Уиндолси, няма студиа.

============
Такие вот дела...

MVC-то ти е една идея по-бързо от формирте- няма ги тия проклети стейтове.

Какво му е например на ViewState-а?
Според мен си е доста силно "оръжие" ако знаеш как и къде да го ползваш

Ако е само за да се оттървеш от вю стейта защо просто не го махнеш?

Като например...

protected override void SavePageStateToPersistenceMedium(object state)
{
base.SavePageStateToPersistenceMedium(null);
}

Верно остава един hidden field който може да се махне и всичко е ОК.
АСП.НЕТ-a ти дава възможност да се намесваш при аутпута и да си правиш каквото си искаш с него преди да се изстреля към уеб сървъра.

А това System.Web.Mvc.ViewPage не е ли просто една "осакътена" уеб форма?

Кой ти ползва MVC Отдавна ползвам MVP патърна и смятам че е по-добър.
А иначе без нито един от 2та патърна става тотално мазало ако проекта стане по-голям.

И най-важното е, че няма стейт и lifecycle на страницата. Това, че си криеш стейта в сесията или по-друг начин не означава, че една страница за грид с 100 резултата е 500КБ. HTTP е стейтлес протокол, това с грозни хакове отдолу.

MVC-то е за разделяне на логиката, на теория. Не че с Уебформите пак не можеш да си я разделиш и не че с MVC пак няма безумия като 20 реда код с ламбда expressions надред ХТМЛ-а, но...

А това, че се ползва ASPX е временно, навярно по нататъка ще се ползва Razor като View Engine. Макар че там пак не са го домилислили, понеже Razor уж се представя като entry-level view engine for WebMatrix (с което ще лъжат ПХП девелопери да пишат АСП), тоест не виждам как ще го позиционират и да се ползва професионално.

Интересно е там, те пичовете много много не знаят какво правят по принцип и самите те предварително не им е ясно какви ги вършат. Примерно LINQ не са знаели, че ще е толкова добър и не са го планирали (един пич в свободното си време си го е написал), Silverlight & WPF съвсем не са им били ясни какво са, сега се оказва че WPF май не трябвало да има, етц. Тоест, недей имай големи надежди в тях, те си правят некви неща просто хората.

А - РЕСТ не е точно Аякс, просто лек протокол да си взимам и закарвам данните от/до сървъра, това е. Ако мога да избегна да пиша сървърен код, го правя.

--
One day it will make sense.

Ще цитирам какво ми беше написал един пич в twitter-а (естествено, че имам twitter):

"MS made ASP.NET server controls/viewstate to port VB6 developers to the web... MVC is to teach them actual web development"

Аз почти 5 години блъсках classic ASP 3.0 на VBScript и като минах на WebForms ми се спести поне половината писане. MVC малко съм го ползвал, цялата работа малко ми мяза на FotM, демек догодина ще измислят нещо ново и както правилно споменаха, ще трябва да се пишат нови версии на продуктите, за да бачкат на новия shit.

Иначе MVC pattern-a е идеен, примерно като пишеш за iPhone нямаш друг избор, освен да го ползваш него.



Eeeeeeeeeeeeeeeaaaaaaasy rider

А - РЕСТ не е точно Аякс, просто лек протокол да си взимам и закарвам данните от/до сървъра, това е.


Тука не съм съгласен.
Извикването на рестфул сървиси от клиента и връщането на данни (xml или jason) си е чист AJAX ама това не е въпроса, така че както и да е.

И пак питам какво му е толкова лошото на стейта и lifecycle на страницата ако знаеш кога, къде и за какво да ги използваш?
Никой не е казал, че стейта се крие в сесията...Просто го премахваш и толкова, ако не ти трябва. Пак казвам, че с традиционните уеб форми имаш възможност да "се намесиш" в даден етап и да промениш аутпута щом желанието е в контрола му.

MVC-то казваш е за разделяне на логиката, на теория...
Ами нали и Codebehind файла беше "за разделяне на логиката"?

Иначе MVC pattern-a е идеен .

Съгласен съм, че е идеен, ама идеен е класичския модел на MVC то.
Т.е. при ъпдейт на модела автоматично да се ъпдейтва и вю-то.
И понеже това няма как да стане в уеба и дай сега да го "поорежем" и да го нагодим, така, че вече след 30г. да земе да се използва най-накрая...

Аз такова MVC съм писал преди 5-6 години само, че с хендлъри наместо контролери. Та затова питам, след като вю-то само може да си поеме рикуеста и да си упдейтва модела, тогава за какво ми е контролера?
Или викаш без контролер нема да е вече MVC

Е не е баш така. Модела принципно трябва да играе ролята на data source - примерно масиви с данни и т.н. докато контролера вече ги фаща тия данни и ги разцъква по UI елементите на view-то. Абе направо си е 3-tier архитектура, ама всяка страница/елемент/view/whatever си е сама за себе си. С две думи - пак е са преоткрили топлата вода, ама тоя път са й турили етикет "pattern"



Eeeeeeeeeeeeeeeaaaaaaasy rider

Та за чиф ми е контролер тука

Kонтролерът може да служи за неща като например:
- идентификация на потребители
- прилагане на филтри (т.нар. Intercepting filters)
- инициализиране на environment-a (prod, dev, test, batch, stage, etc), което само по себе си включва още безброй неща като сетване на логгери, кеш, дебъг инфо... и т.н.

ако самото View си хит-ва бизнес логиката - да ако работиш сам, можеш и всичко в един файл на наблъскаш, пак ще фунционира. Ако обаче имаш дизайнер, тогава може би ще резбереш предимството от обособяване на отделно view и премахване нa всякаква логика от него

ако самото View си хит-ва бизнес логиката - да ако работиш сам, можеш и всичко в един файл на наблъскаш, пак ще фунционира. Ако обаче имаш дизайнер, тогава може би ще резбереш предимството от обособяване на отделно view и премахване нa всякаква логика от него

Тва нещо не го разбирам...би ли обяснил малко по-подробно?

Щото аз досега си мислех, че при традиционните уеб форми codebehind-а е именно за това?

Искаш да кажеш, че при уеб формите няма възможност как да работят едновременно дизайнери и програмисти ли?

Kонтролерът може да служи за неща като например:
- идентификация на потребители
- прилагане на филтри (т.нар. Intercepting filters)
- инициализиране на environment-a (prod, dev, test, batch, stage, etc), което само по себе си включва още безброй неща като сетване на логгери, кеш, дебъг инфо... и т.н.

За идентификация на потребители имаш Http moduls. За чиф ми е да стигам до контролера за да идентифицирам потребителите, след като мога да го направя в много по-ранен етап? За филтрите...с уеб формите имам същите възможности та даже и по-добри

А сега да ти задам въпроса...След като с MVC имаш пълен контрол върху html-а за какво са ти intercepting filters???

Кой ти ползва MVC Отдавна ползвам MVP патърна и смятам че е по-добър.

Значи пишеш десктоп приложения...ОК.

А иначе без нито един от 2та патърна става тотално мазало ако проекта стане по-голям

ОК, кажи сега кое е онова нещо, което ме застрахова от бози използвайки тези 2 патерна??

Щото от личен опит, а и не само мой знам, че бозите се създават не толкова заради избраната архитектура, а заради липсата на дисциплина, общи конвенции и липса на контрол

не, пиша си веб, но не е на .нет, но един приятел като му обясних колко гъзари мвп-то той надгради аеспе-то с мвп фреймуърк.

найстина нищо не спира да се пишат бози. Просто тея патърни ти позволяват по-лесна подръжка, рефакторинг, даже и модулност ако си го направиш яко, от което следва по-малка нужда да се променя код, което пък значи по-малка вероятност да се счупи работещ код.

Несеризно е да се обсъждат такива теми ако не вложиш нещо оригнално с пример и кейс и т.н.. Иначе става жалка помия като на българска маркетинг/уеб/тех/гей конференция. Никой не е направаил нищо и няма нищо за показване. Вместо това нърдове повтарят назубрени изречения от "интернета" и се кефят на контрабанден хардуер внесен от някой sandwich artist дето се връща от студентска бригада.