ASP.NET MVC vs WebForms...

ако самото View си хит-ва бизнес логиката ... Щото аз досега си мислех, че при традиционните уеб форми codebehind-а е именно за това не мога да разбера позицията ти?
Иначе както каза cristal_reaver, MVР е къде къде по-уместно за използване. Намирам за глупаво да заговаряш БД от view-то или въобще да вкарваш каквато и да е логика в него. Което не означава, че е невъзможно де, на теб щом ти харесва, никой не те спира

Опсс, това с идентификацията на потребителите няма място, моя грешка


След като с MVC имаш пълен контрол върху html-а за какво са ти intercepting filters - щот имам front controller. И той е първия, който "поема" рикуеста, изпъляват се сетнатите пре-филтри и тогава се зарежда контролера на търсения модул. Въпросният контролер интерактва с модела и получените данни ги праща на view-то, което "само" ги рендира (примерен сценарии). Ако под пълен контрол на хтмл-а разбираш свободата да организираш дом-струкурата на страницата както сметнеш за добре, без това да се отрази на информацията, която рендираш - верно е. Но сам забелязваш кога се рендира и кога се изпълняват филтрите. Нищо де, ако не им намираш приложение (на филтрите), можеш и без тях да минеш

Намирам за глупаво да заговаряш БД от view-то или въобще да вкарваш каквато и да е логика в него

Чакай малко...за кво БД говорим?
Защо да правя това от View-то след като имам бизнес логика, която ще се погрижи за "заговарянето на БД-то" чрез интерфейс?

Кажи ми, или просто обясни позицията си по следания въпрос...Какво повече ни дава (на нас разработчиците) MVC патерна vs традиционните уеб форми?

Понеже искаше да ползваш бизнес логика във view-то, което си е долу горе същото

Предимства:
- модуларност на кода (знам, звучи банално, нo е вярно)
- от модулралността пък по-лесен рефакторинг,
- лесно и бързо интегриране на нови "модули"
- организираш си DOM-структурата както си искаш, което е
- по-лесна работа за дизайнерите
- по-лесна аякс интеграция
- unit tests


Сега, то пак си зависи от конкретната имплементация.

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

Ето, това е отговор на една част от моя въпрос...а именно...използвам MVC/MVP/MVVM щото знайш ли...един мой приятел, роднина, гуру ми каза, че тва кърти мифки просто

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

Смяташ ли, че традиционните уеб фроми подкрепени с бизнес логика, дейта аксес логика и т.н. ти дават по-малко? Смяташ ли, че модулността е по-лесна за имплементация, както и поддръжката при MVC модела?
Все пак говорим за OOP и ООД?

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

По отношение на промяната на кода...не съм съгласен категорично. Независимо каква архитектура е наложена, кода винаги търпи промени. Въпроса е какво ще ти струва за да го промениш
В този ред на мисли не смятам, че MVC патерна ще ти помогне...

По отношение на рефакторинг...бих искал да споделиш защо смяташ, че MVC е по-лесно за юнит тестинг...(щото нали без юнит тестинг рефакторинг няма).
View-то няма смисъл от тестване, защото няма логика...бизнес логиката може да се тества и при положение, че си изполваш традиционните уеб форми.
Значи, MVC ти позволява да тестваш не само Modela-а, a и Controler-а...ОК
Ама ако имаш дори и най-малката логика в контролера, която се нуждае от тестване, значи нещо си сбъркал...

модуларност, рефакторинг, DOM организация (тва честно казано не знам какво общо има с MVC при положение, че е проблем при клиента и не зависи от MVC),по-лесна работа за дизайнерите (ОК, с какво MVC патерна улеснява работата на дизайнерите??? )

по-лесна аякс интеграция
И какво му е лесното при AJAX имплементацията?
Би ли обяснил?

Както и да ти го преразкажа, като си тръгнал на "хит-ваш бизнес логика от View-то" MVC наистина не би имало нищо общо с това

Дерзай.

НЕ, ползвам го щото съм сметнал че ми е полезно. Щото написах един проект без и един със и виждам колко по-лесно сега 2я се екстендва.
И човека който си написа фреймуърка не е пеост бот, че като е чул нещо и давай, ами е осъзнал идеята.

Не ги знам тея веб форми, ако ми говоеиш за асп смесено с ц# код, е как да не е манжа с грозде бе.
Къде се прави тази бизнес логика в веб формите? Кво става ако направя промени там?
Направи си нещата да са максимално независими едно от др и ще видиш колко малко код ще се наложи да пипнеш, да може би не зависи отва от мвц-то

Кой квото иска туй да ползва все ми е куро, като е труден съпорта повече пари ще се смучат за едни е радост за други болка.
Най-малкото налага цялостен общ подход който иначе ти трябва да си го мислиш, а дали ще го измислиш по-добре не се знае за туй хората играят на сигурно. Ако се чувстваш ограничен не го ползвай.
Говориш че без него е по-добре, така и не видях конкретен пример в който е по-добре.
Аз ще ти кажа още един, ако имаме фронт енд дев, бизнес логика дев и ескюел дев 3мата могат да си цъкат по-свлята част без ниакакви проблеми, като никой не разбира какво прави кода на другия. Фронт енд дева знае само асп тагове и хтмл, той не знае ц#, ц# дева не знае ескюел, не му е работа да се меси на дизайнера, ескюел дева си пише заявките и дефинира обектите модели. Всички са независими.
Това в твоя случай как се псотига.
В крайна сметка пак до корпоративното мислене стигаме където всеки дев прави своята част.

Несеризно е да се обсъждат такива теми ако не вложиш нещо оригнално с пример и кейс и т.н..

Какъв пример и какъв кейс искаш?
Ако имаш нещо за/против казваш си го...тва е идеята.

А ако все пак държиш на "примери и кейзове", повярвай ми, бих те заринал с такива, но не смятам, че за един "опитен уеб разработчик" са му нужни жокери

контрабанден хардуер внесен от някой sandwich artist дето се връща от студентска бригада

Немам чак такова въображение, че да коментирам това...

Хората добре са ти казали по-горе - ти ако искаш да пишеш зле, никакво MVC няма да сте спаси. Както и ако пишеш добре, спокойно Уебформите може да си ги направиш екстра.

Лично аз бих писал нов проект на MVC заради 4-5 неща

- няма page lifecycle
- няма стейт
- по-лесно се тества
- няма ClientID / INamingContainer / FindControl простотии
- има стандарт за фолдерите в проекта. Знаеш къде са ти скриптовете, къде контролерите, етц и нямаш много много свобода. Това са го взели от Релси и е супер. Иначе всеки си прави каквото искаш.
- получаваш по-дефаулт СЕО френдли УРЛ-та.
- така или иначе пиша каквото мога на Джаваскрипт, не ми трябва да е много дебела сървърния стек отдолу.

Това е. Всичко това изброено горе можеш и с Уебформи да го направиш спокойно ако имаш опит, но ти гарантирам, че първите 2-3 години ще се чудиш защо трябва да се пише собствен рекурсивен FindControl, какво е page lifecycle catch-up (динамични контроли добавени в по-късен етап от ОнИнит си викат всичко по-лайфсайкъла наново), защо нещо в постбек евента не е както трябва като стойност, клиентските ИД-та, ще правиш фолдери както ти скимне и след няколко месеца обикновено имаш сериозен мес, освен ако не си много опитен.

--
One day it will make sense.

Ми щото много хора ми го разказват/преразказват, а и аз имам не малък опит та затова задавам този въпрос

а бе мвц-то не идва от рейлса

Кое MVC? MVC е pattern, и Релси далеч не са първата имплементация, просто са най-популярната.

Няма как АСП.НЕТ MVC да идва от Релси, все пак са съвсем различни платформи и АСП.НЕТ MVC трябва да се съобразява с тези 8 години дебилни девелопери, които са създали. Session, Cache, Request, Response, HttpContext, etc - всички тези неща са общи и за УебФормс и за АСП.НЕТ MVC.

От друга страна можеш да си сигурен, че са гледали от Релси много и има много "взаимствани" идеи, което е добре разбира се - щом работи, го ползвай.

А ако се съмняваш, че АСП.НЕТ Уебформс девелоперите са най-дебилното племе като цяло, един интересен факт - при положение, че ПХП се ползва грубо казано 4-5 пъти повече от АСП.НЕТ за уеб проекти, единствената държава в света дето има повече АСП.НЕТ програмисти от ПХП такива е Индия.

[линк]

Последните 8 години си изкарвам хляба да си говоря с АСП.НЕТ програмисти и трябва да ми повярваш тука, Уебформите просто пасват перфектно на индийско-дебилен начин на мислене.

--
One day it will make sense.

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

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

Хората добре са ти казали по-горе - ти ако искаш да пишеш зле, никакво MVC няма да сте спаси.

Гуро, не искам да навлизаме в подробности, но ми се ще да споделиш следното: Защо мамка му смяташ че MVC патерна е едно от условията (дори и да не е необходимото и достатъчно условие) който може да те спаси от зле написан код

Казваш http протокола е stateless и всичко отдолу е dirty hacks... OK.
Ама защо тогава продължава да се използва сесията на уеб сървърва??? Не е ли и това един вид dirty hacks ?

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

Казваш по-лесно се тества...И кво, тестваш контролера ли...? Щото и с традиционните уеб форми си се тества бизнес логиката...Кво повече имаш да тестваш?

Казваш няма КлиентИД...ФайндКонтрол...аре стига бе...Тва ли е проблема? Ми имаш си клиентски библиотеки (джейКюери например)?

Казваш получаваш по-дефаулт СЕО френдли УРЛ-та. Колко "мастодонти" в уеба имат френдли УРЛ-та? Фейсбоок-а има ли френдли УРЛ-та?

За Релси - Релсите са МВЦ уеб-фреймуърк за Руби и не са толкова млади вече, 2004-а година е първия рилийз, тоест са на 6 години, което за уеб технологии си е направо за пенсия.

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

За Оракъл Формс - всичко на Оракъл е огромен шит, но с добрия модел може да носи добри пари на така наречените "integration partners". Oracle Integration Partners обикновено са най-дървените, корумпирани и тарикатски фирми като Технологика и Фадата, но това важи не само за България, а и навсякъде. Едни просто форми и репорти дето може да се направят за месец от 5 човека с Оракъл Формс спокойно можеш да изкараш една фирма от 100 човека заета 5 години.

Тоест има бизнес и затова. Неслучайно шефчето на Технологика си празнува рождения ден с 500 бели гълъба и 5000 пеперуди пуснати да летят в сублимния момент в резиденция Лозенец.

--
One day it will make sense.

Не, аз съм съгласен с теб, в смисъл очевидно ги чаткаш нещата. За мен лично - няма значение голямо. Ако кода в контролерите е написан добре (без значение дали в МВЦ или УебФормс) би трябвало да може да се тества и без HttpContext / Request / Response - тоест при добре написан код няма проблеми.

Интересния момент е, че Views в АСП.НЕТ MVC и сега не могат да се тестват добре, чак като пуснат Razor като view engine ще може. Така че и тука съм съгласен.

Просто цялата АСП.НЕТ Уебформс абстракция противоречи на уеб/хттп като цяло и всичко с контролите, клиент-ид, файндкотрол, стейт, етц е наистина много мръсен хак. Като цяло работи добре очевидно - ако не беше така, нямаше да е навярно в топ 3 на най-популярните уеб платформи, просто аз лично не бих почнал нов проект на Уебформс.

--
One day it will make sense.

В началото мислех да ти отговоря на всеки абзац поотделно...
Ама в крайна сметка реших, че не си заслужава

П.П. Пич си, много четеш...явно програмирането те вълнува, което е хубаво...и според мен това е необходимо(въпреки, че не е достаъчно) условие да израстваш.

да юнит тестваш пропърли, да имаш горе долу по един екшън на страница
Ок, ама кажи ми следното...какво означава да юнит тестваш пропърли

А иначе като цяло съм съгласен с теб.

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

Heavy rings hold cigarettes
Up to lips that time forgets

Така, да, и аз така мисля. Едно АСП.НЕТ МВЦ приложение горе долу знаеш какво ще получиш - ентити фреймуърк за модела, контролери и ако е умен девелопера почти нищо във View освен Html. На клиента jQuery. Всичко подредено по фолдери както си трябва, Models, Views, Controllers. И един юнит тест проект.

При уебформите получавам такива проекти от клиентите, че просто е смешно какъв мес е 99%. Вече съм се повредил обаче и всичко разбирам за 5 минути, което не е хубаво.

Като получавам МВЦ проект се оправям за 30 сек, Уебформите ми трябват 5 мин докато разбера кой/как/какво е "творил".

--
One day it will make sense.