EDUARD SAPOTSKI,

http://ru.wikipedia.org/wiki/REST

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

одного только не могу понять. как клиент может вообще такие задачи ставить? а он случайно не объявляет для разработчика набор переменных, которые должны обязательно быть в коде и список методов, один из которых «сделать_хорошо()»? ))

МСУ,

вы очень адекватно ответили. с этим, прям и не поспоришь. в общем-то да, ломать стереотипы можно, а иногда даже нужно. но REST, это не стереотип, это архитектура веб. все сервера работают на этом принципе.

например, веб-сокеты, появившиеся не так уж и давно не являются нарушением REST архитектуры, и не ломают её, они её качественно дополняют. AJAX полностю укладывается в архитектуру REST.

такого количества кривых рук программистов на веб-форм наверное нигде больше нет. ни о чем не заставляет задуматься? нет? согласен, есть некоторое количество виртуозов, чувствующих себя на веб-форм кофмортно. но если начинать дружить несколько технологий, ведь в общий стек с MVC легко (я бы даже сказал, почти безукоризненно) ложатся мощные JS-фреймворки (бекбон, кнокаут...), и даже серверные движки типа node.js, все эт в одной архитектуре. я считаю, что это очень удобно и никогда не посоветую никому курить веб-формс, потому что наверняка обнаружатся проблемы с кривыми руками...

ну а те, кто выкурили все маны, прониклись и приняли концепцию веб-формс, мои глубочайшие поздравления. но нам, простым смертным, слишком далеко до этого левела :)

МСУhVosttодного только не могу понять. как клиент может вообще такие задачи ставить? а он случайно не объявляет для разработчика набор переменных, которые должны обязательно быть в коде и список методов, один из которых «сделать_хорошо()»? ))
Ну вот видишь, если ты не встречал, это ведь не означает, что такого нет, верно ведь? Открою тебе секрет - такое сплошь и рядом. Банальный пример, мы на аутсорс (через подряд, через интегратора и т.д.) отдаем проект команде, чтобы нам сделали решение. Решение после этого упадет к нам на поддержку и развитие. На внешку мы отдаем проект для экономии своих ресурсов, которые сейчас заняты на других более приоритетных проектах. Разумеется, мы будем диктовать условия - на каких технологиях писать решение, какую СУБД использовать, какой язык использовать, вопросы лицензирования и пр.

и все же, это совсем другое. если ты уже давно в теме веб-формс, ты берешь проект или часть проекта на аутсорс, делаешь её, там.. потом сдаешь... потом переделываешь... потом опять сдаешь... ну или что-то вроде того. с такими ребятами спорить так же глупо, как спорить с действующим извозчиком на лошади, типа «бросай ты свою клячу, пересажывайся на майбах!» ))

я именно про выбор средств разработчиком до старта проекта. и когда заказчику параллельно, на чем это будет сделано, лишь бы ТЗ было выполнено и все работало в срок. ну может еще какие издержки потребуются на сопровождение, ведь чем мудреннее технология, тем дороже потом программист. поэтому выбирать надо что-то такое, что сможет быстрее освоить веб-программер, даже если он пол жизни ездил на рельсах, с разжиженными перлом мозгами в детстве ))

handmadeFromRuhVostt,
прости вы считаете что бекбон и прочую тему в формы не засунуть?) и все разработчики на асп мвц такие крутые перцы?: ))) вопрос рук всегда будет актуален...щас скианыч прийдет и всех потушит рестфул сервисами!!) отдельное спасибо ему ..увлекло и понравилось)

ну действительно, чоб бекбон в веб-формс не засунуть, где ему еще-то быть? )) засунуть можно. вы картинку про хлебный трамвай видели? или вам запостить? :)

МСУ,

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

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

при усложнении приложений, границы фреймворков начинают стираться, поэтому один и тот же программист скорее всего сделает очень похожие вещи, что на веб-формс, что на мвц. я своими глазами видел как один программер 7 лет назад сделал на веб-форм свой мвц. при чем не с точки базового хендлера, а со стартовой точки веб-формс.

ну в общем вы поняли :) чувствуете, что попахивает кривыми руками? ))

МСУ,

про MVC ниже 3-ей версии обсолютно согласен. я на том его этапе развития чуть для себя его не похоронил.

EDUARD SAPOTSKIhVosttодного только не могу понять. как клиент может вообще такие задачи ставить? а он случайно не объявляет для разработчика набор переменных, которые должны обязательно быть в коде и список методов, один из которых «сделать_хорошо()»? )) Ну если этого не можешь понять то до ПМ-а тебе еще очень далеко. Никогда не задумывался почему можно в автосалоне заказать машину с определенной комплектацией и дизайном?

пм — прожект менегер? не хочу )) ...но приходится

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

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

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

лан, холиворить похоже над приходить в пятницу )) всем удачного дня!

handmadeFromRuвьюшка не должна грузить себе что то еще, а должна только отображать..хотите кашу вперед... и это фейл если еще есть доступ вьюшки к бд/орму

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

поясню. например, у меня три различных вьюшки для одного и того же. для десктопов, для мобилок ну и для чтения (печати, а также олдскул браузеров, включая текстовых). где-то нужно больше информации отобразить, где-то меньше. контроллеру, что там на выходе обычно знать ни к чему. ну это если следовать чистой мвс логике. а еще ведь могут быть атом/фиды и другие причины вью не заниматься фигней, заставляя всю подинфраструктуру передачи данных повторять по 10 раз.

МСУЧего чего? Ты что, во вьюху пихаешь IQueryable члены? С дубу что-ли рухнул? :)
Во-первых, датаконтекст будет уже задестроен, трансляции SQL никакой уже не будет. Во-вторых, ты что, используешь глобальный (кеш, статика, аппликейшен) датаконтекст EF?

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

юзинг-отдай-данные-умри это из учебных примеров, весьма хорош для начинаний ))