Comments 166
Пока вода-водой, но дальше будет интереснее :)
Продолжай.
Продолжай.
Вообще, хотел все уместить в одной статье, но очень огромная она бы получилась.
Да и переходить сразу к кодингу тоже неправильно, так как много людей привыкли к WebForms и смотрели бы они большими глазами на код.
Мне кажется, теория не есть вода :)
Да и переходить сразу к кодингу тоже неправильно, так как много людей привыкли к WebForms и смотрели бы они большими глазами на код.
Мне кажется, теория не есть вода :)
Мне кажется хорошо написано, все ясно и понятно. Вот почитал, и что-то захотелось с PHP на ASP.NET перейти... Или хотя бы попробовать =) Для ASP ведь нужен хостинг на Win Server?
Да. Но цены сейчас вполне соизмеримы с PHP хостингом. Если сервер свой, то 400$ за Windows Server 2008 Web Edition, думаю, не такие уж большие деньги.
мне не понятна ваша логика, ведь в этом плане пых уже давно впереди.
В каком именно "таком" плане пых впереди?
в плане шаблонов и использования хелперов, роутов. уже давно есть куча различных библиотек для сих целей
Вы знаете, а вот .NET (или даже простой ASP) в плане ООП давно впереди, но это никак не помешало PHP сделать на ООП упор в пятой версии..
вы писали - Вот почитал, и что-то захотелось с PHP на ASP.NET перейти..
вот я и высказался что всё описанное в статье есть давно в пыхе и не является фактором для перехода на асп. об ооп я пока не спорил, хотя уже можно пробовать.
вот я и высказался что всё описанное в статье есть давно в пыхе и не является фактором для перехода на асп. об ооп я пока не спорил, хотя уже можно пробовать.
Видимо мы друг друга не до конца поняли. Мне захотелось перейти на ASP.NET не из-за одного только появления там MVC :) Конечно в PHP это все уже давно существует, но есть еще много факторов, которые я увидел в статье, да и сам знал ранее, просто появление нормального MVC подталкивает к изучению ASP еще больше :)
Лично мне нравится Visual Studio, где все сделано красиво, профессионально, ООП'шно и т.п., хоть у студии и есть свои недостатки, но хочется попробовать писать веб-приложения используя этот мощный инструмент. Также считаю очень удобным подход .NET'a, когда можно писать на множестве языков от JavaScript до C#. Ну и просто хочется узнать что-то новое, интересное )
Я не собирался доказывать крутость ASP.NET по сравнению с PHP, я пых люблю и уважаю, но это не мешает мне изучать новые языки и технологии и получать от этого удовольствие :)
Лично мне нравится Visual Studio, где все сделано красиво, профессионально, ООП'шно и т.п., хоть у студии и есть свои недостатки, но хочется попробовать писать веб-приложения используя этот мощный инструмент. Также считаю очень удобным подход .NET'a, когда можно писать на множестве языков от JavaScript до C#. Ну и просто хочется узнать что-то новое, интересное )
Я не собирался доказывать крутость ASP.NET по сравнению с PHP, я пых люблю и уважаю, но это не мешает мне изучать новые языки и технологии и получать от этого удовольствие :)
UFO just landed and posted this here
Хотелось бы про самую интересную часть услышать - взаимодействие с БД через модели - как вообще это происходит в ASP.NET MVC, таблицы сами создаются по моделям, код моделей сам генерится по таблицам, или все руками писать. А добавление, изменение, выборка (!) данных как происходит? Понимаю, что есть Гугль, но раз уж начал статью писать... :)
В ASP.NET MVC нет какого-то стандартного способа работы с данными. Полная свобода выбора! Но я бы рекомендовал обратить внимание на следующие разработки Microsoft
Linq To Sql - http://tinyurl.com/LinqToSql
ADO ENtity - http://tinyurl.com/AdoEntity
Linq To Sql - http://tinyurl.com/LinqToSql
ADO ENtity - http://tinyurl.com/AdoEntity
А также ADO.NET Astoria Data Services.
Ага, когда чего-то нужного нет, принято называть это "свобода выбора" :)
Спасибо за ссылки, посмотрю обязательно, возможно, что скоро будет проект на ASP.NET.
Спасибо за ссылки, посмотрю обязательно, возможно, что скоро будет проект на ASP.NET.
>> Ага, когда чего-то нужного нет, принято называть это "свобода выбора" :)
Все есть. ASP.NET MVC не навязывает никакие фреймворки. Используйте то, что вам больше подходит.
Еще есть интересный проект SubSonic
Все есть. ASP.NET MVC не навязывает никакие фреймворки. Используйте то, что вам больше подходит.
Еще есть интересный проект SubSonic
Вы же сами пишете:
>> В ASP.NET MVC нет какого-то стандартного способа работы с данными.
А отсутствие стандарта в чем бы то ни было - большой минус, который порождает несогласованность и, в худших случаях, "грязь".
Только не поймите неправильно, я не пытаюсь сказать, что теперь ASP.NET MVC это плохо и им нельзя пользоваться - я просто сравнивал с Django и стало интересно, как с взаимодействием с данными дела обстоят у ASP.NET MVC. Оказалось, что никак :), стандартных механизмов нет. Огорчился, но не слишком.
>> В ASP.NET MVC нет какого-то стандартного способа работы с данными.
А отсутствие стандарта в чем бы то ни было - большой минус, который порождает несогласованность и, в худших случаях, "грязь".
Только не поймите неправильно, я не пытаюсь сказать, что теперь ASP.NET MVC это плохо и им нельзя пользоваться - я просто сравнивал с Django и стало интересно, как с взаимодействием с данными дела обстоят у ASP.NET MVC. Оказалось, что никак :), стандартных механизмов нет. Огорчился, но не слишком.
Так это не недостаток, а преимущество!
Во-первых, можно использовать готовые библиотеки.
Во-вторых, можно сделать что-то свое, если готовых вариантов нет.
Так что не надо огорчаться :)
Во-первых, можно использовать готовые библиотеки.
Во-вторых, можно сделать что-то свое, если готовых вариантов нет.
Так что не надо огорчаться :)
Не пользовались вы Django, так все удобно и так цельно... :) И еще - писать свое?! Это можно делать разве что в целях прокачаться, но когда есть сжатые сроки, то это нехорошо.
Писать свое можно не только для того, чтобы "прокачаться" =)
Писать свои велосипеды, когда уже есть другие, можно только для этого. Отмазка, что "мой велосипед более удобный" при этом в общем (и данном) случае не работает.
Мне кажется вы о разных вещах говорите.
Никто же вас не заставляет писать свои компоненты для непосредственной работы с данными. Используйте тот же LINQ to SQL или Entity Framework. Так как это родные библиотеки .NET можно смело говорить, что они станут стандартом с релизом .NET SP1.
Если вас эти решения не устроят, то тогда уже будете писать что-то свое, использовать сторонние библиотеки, тот же NHibernate, возможно вам будет больше подуше. Намного хуже было бы, если бы с MVC можно было использовать _только_ LINQ to SQL, например.
Никто же вас не заставляет писать свои компоненты для непосредственной работы с данными. Используйте тот же LINQ to SQL или Entity Framework. Так как это родные библиотеки .NET можно смело говорить, что они станут стандартом с релизом .NET SP1.
Если вас эти решения не устроят, то тогда уже будете писать что-то свое, использовать сторонние библиотеки, тот же NHibernate, возможно вам будет больше подуше. Намного хуже было бы, если бы с MVC можно было использовать _только_ LINQ to SQL, например.
Вы пытаетесь аргументировать против того, о чем ничего не знаете.
Да, Django хороший фреймворк на Python'е со своими наработками, довольно цельный и классный.
Здесь речь про ASP.NET MVC Framework. Прежде чем говорить что-либо, рекомендуется как минимум ознакомиться с предметом. И не надо нести откровенную херню.
Преимущество ASP.NET MVC в том, что там есть все стандартное (шаблонный движок, система формирования маршрутов и так далее), при этом компоненты так развязаны, что при желании можно заменить любой из них. Хотите использовать YAML, XSLT или другой шаблонизатор? Ради бога. Все очень организчно вписывается без нарушения целостности и идеологии.
О каких, нахрен, стандартных механизмах доступа к данным идет речь? ASP.NET MVC - реализация MVC-фреймворка для ASP.NET. Ключевое слово здесь - ASP.NET. А это значит, что и .NET как таковой тоже. Неважно в какого вида приложении, хоть в десктопном, хоть в мобильном, можно применять те же самые (кстати, очень удобные) механизмы доступа к данным. И это все чушь по поводу отсутствия стандартных (а в случае с ASP.NET НЕстандартные обычно написаны так, что не нужно пользоваться чем-то еще).
Для ASP.NET можно выбрать на свое усмотрение как минимум 4 разные ORM:
- LINQ to SQL;
- LINQ to Entities и ADO.NET Entity Framework;
- LINQ to NHibernate и сам NHibernate;
- SubSonic (обалденная вещь с реализацией паттерна Active Record).
Есть еще варианты, да или вообще избрать любой способ хранения данных и работы с ними. MVC Framework вообще никакой связи с СУБД не имеет и хранение данных никак не зависит от реализации MVC.
То, что написал gaech - "В ASP.NET MVC нет какого-то стандартного способа работы с данными." и "Полная свобода выбора!". Еще раз прочитайте. Имеется в виду, что нет какого-то навязанного способа работать с данными "только так и никак больше". Механизмов только стандартных предлагается несколько, предоставлена полная свобода выбора, разработчик использует то, что ему наиболее удобно.
Мы, например, используем все 4 вышеперечисленных технологии доступа к данным в тех или иных проектах.
Учите матчасть.
Да, Django хороший фреймворк на Python'е со своими наработками, довольно цельный и классный.
Здесь речь про ASP.NET MVC Framework. Прежде чем говорить что-либо, рекомендуется как минимум ознакомиться с предметом. И не надо нести откровенную херню.
Преимущество ASP.NET MVC в том, что там есть все стандартное (шаблонный движок, система формирования маршрутов и так далее), при этом компоненты так развязаны, что при желании можно заменить любой из них. Хотите использовать YAML, XSLT или другой шаблонизатор? Ради бога. Все очень организчно вписывается без нарушения целостности и идеологии.
О каких, нахрен, стандартных механизмах доступа к данным идет речь? ASP.NET MVC - реализация MVC-фреймворка для ASP.NET. Ключевое слово здесь - ASP.NET. А это значит, что и .NET как таковой тоже. Неважно в какого вида приложении, хоть в десктопном, хоть в мобильном, можно применять те же самые (кстати, очень удобные) механизмы доступа к данным. И это все чушь по поводу отсутствия стандартных (а в случае с ASP.NET НЕстандартные обычно написаны так, что не нужно пользоваться чем-то еще).
Для ASP.NET можно выбрать на свое усмотрение как минимум 4 разные ORM:
- LINQ to SQL;
- LINQ to Entities и ADO.NET Entity Framework;
- LINQ to NHibernate и сам NHibernate;
- SubSonic (обалденная вещь с реализацией паттерна Active Record).
Есть еще варианты, да или вообще избрать любой способ хранения данных и работы с ними. MVC Framework вообще никакой связи с СУБД не имеет и хранение данных никак не зависит от реализации MVC.
То, что написал gaech - "В ASP.NET MVC нет какого-то стандартного способа работы с данными." и "Полная свобода выбора!". Еще раз прочитайте. Имеется в виду, что нет какого-то навязанного способа работать с данными "только так и никак больше". Механизмов только стандартных предлагается несколько, предоставлена полная свобода выбора, разработчик использует то, что ему наиболее удобно.
Мы, например, используем все 4 вышеперечисленных технологии доступа к данным в тех или иных проектах.
Учите матчасть.
>> И не надо нести откровенную херню.
>> О каких, нахрен, стандартных механизмах доступа к данным идет речь?
>> Еще раз прочитайте.
Вам лично посоветовал бы 1 - сначала к походить на курсы иглорефлексотерапии, говорят, нервы успокаивает, и 2 - погуглить по словам "этика общения, уважение к собеседнику". Непонятно, чего люди хотят добиться такими коментами, ибо добиться можно только одного - вот лично на ваше мнение мне глубоко "похрену" стало.
>> О каких, нахрен, стандартных механизмах доступа к данным идет речь?
>> Еще раз прочитайте.
Вам лично посоветовал бы 1 - сначала к походить на курсы иглорефлексотерапии, говорят, нервы успокаивает, и 2 - погуглить по словам "этика общения, уважение к собеседнику". Непонятно, чего люди хотят добиться такими коментами, ибо добиться можно только одного - вот лично на ваше мнение мне глубоко "похрену" стало.
Очень зря. Я написал все в точности, как есть.
Не надо советовать мне посещать всякого рода курсы.
То, как написан пост, отнюдь не из за нервов, не сомневайтесь в том, что я всегда думаю, что делаю.
Написано так экспрессивно специально. Думаю, многим не нравится, когда человек, не поинтересовавшись деталями проблемы, с огромными шорами, из за которых не видно ничего кроме "своей" технологии, пытается навязать свои аргументы и видение проблемы. Возможно, немного утрированно, но суть, я думаю, вы уловили.
Не надо советовать мне посещать всякого рода курсы.
То, как написан пост, отнюдь не из за нервов, не сомневайтесь в том, что я всегда думаю, что делаю.
Написано так экспрессивно специально. Думаю, многим не нравится, когда человек, не поинтересовавшись деталями проблемы, с огромными шорами, из за которых не видно ничего кроме "своей" технологии, пытается навязать свои аргументы и видение проблемы. Возможно, немного утрированно, но суть, я думаю, вы уловили.
А вот не попали вы. Нет у меня "своей" технологии и на ASP.NET были проекты и первых бетах MVC успел поковыряться. Шоров не имею тем более, после 8 лет разработки на различных языках/платформах знаю, что почти все относительно. Вы наверное, не только слишком экспрессивно пишете, но и слишком с выражением читаете.
И еще я думаю, что еще большему числу людей не нравится, когда им пишут в стиле "И не надо нести откровенную херню". Японец один сказал - "уважайте человека насколько можете, пока он не докажет вам, что не достоин уважения". Так вот - идите фтопку, Vasilio, заколебали вы своей агрессивностью.
И еще я думаю, что еще большему числу людей не нравится, когда им пишут в стиле "И не надо нести откровенную херню". Японец один сказал - "уважайте человека насколько можете, пока он не докажет вам, что не достоин уважения". Так вот - идите фтопку, Vasilio, заколебали вы своей агрессивностью.
Ну судя по обсуждению, опыт на ASP.NET был не такой уж и обширный, если не в курсе о механизмах доступа к данным. Ну не буду спорить ни о чем.
Насчет уважения я согласен, а про какую агрессивность вы говорите - понятия не имею, ее и в помине не было.
P.S. "И не надо нести откровенную херню" не нравится только тем, кто ее несет и не хочет смириться с этим фактом :) Без обид, ничего личного.
Насчет уважения я согласен, а про какую агрессивность вы говорите - понятия не имею, ее и в помине не было.
P.S. "И не надо нести откровенную херню" не нравится только тем, кто ее несет и не хочет смириться с этим фактом :) Без обид, ничего личного.
>> если не в курсе о механизмах доступа к данным
Говорите, что знакомы с Django? Так вот - там есть встроенный ORM - чрезвычайно (!) удобный. Вот о таких механизмах, которые удачно вписываются в MVC паттерн, я и говорю. И да, я знаком с NHibernate - он тяжелый, думаю, здесь вы согласитесь со мной, если у вас в генах не вшит инстинкт спорить. Так вот - захотелось мне значит узнать, может чего появилось "от производителя" полегче - и вот такая дискуссия ни о чем получилась.
P.S. Далеко пойдете Вазилио, вас фтопку, а вы как ни в чем ни бывало...
PP.S "И не надо нести откровенную херню" не нравится всем нормальным человекам.
Говорите, что знакомы с Django? Так вот - там есть встроенный ORM - чрезвычайно (!) удобный. Вот о таких механизмах, которые удачно вписываются в MVC паттерн, я и говорю. И да, я знаком с NHibernate - он тяжелый, думаю, здесь вы согласитесь со мной, если у вас в генах не вшит инстинкт спорить. Так вот - захотелось мне значит узнать, может чего появилось "от производителя" полегче - и вот такая дискуссия ни о чем получилась.
P.S. Далеко пойдете Вазилио, вас фтопку, а вы как ни в чем ни бывало...
PP.S "И не надо нести откровенную херню" не нравится всем нормальным человекам.
NHibernate - да, тяжел, согласен. Но он для своих задач. Это не только ORM, а целый фреймворк для доступа к данным. Впрочем, мы предпочитаем LINQ to SQL и SubSonic вместо него. В последнее время также используем ADO.NET Entity Framework, который хоть и наворочен, но достаточно прост в использовании и понятен.
P.S. Инстинкта спорить у меня нет, я только привожу свои аргументы, когда с чем-то несогласен, вот и все.
P.S. Инстинкта спорить у меня нет, я только привожу свои аргументы, когда с чем-то несогласен, вот и все.
5. RSDN Business Logic Toolkit - http://rsdn.ru/summary/3308.xml
Когда есть что то готовое и тольк это - вот это и есть настоящее ограничение в свободе. Когда ты не можешь выирать ничего кроме этого.
Здесь же у нас довольна мощная тенология для упрощенного создания сайтов. И возможность гибко менять поведение, которое нам нужно.
Здесь же у нас довольна мощная тенология для упрощенного создания сайтов. И возможность гибко менять поведение, которое нам нужно.
Причем к ASP.NET MVC работа с данными? работайте с ними как пожелаете :) ASP.NET MVC создан для удобного проектирования/создания ASP.NET веб-приложений по концепции MVC. А для работы с данными используйте или средства от Microsoft, или, например, тот же NHibernate.
Ну так Model в MVC это что по вашему? Представление данных и есть, причем, в подавляющем большинстве случаев это данные из БД. Поэтому многие MVC-решения сопровождаются неким ORM - RoR, Django тому примеры. Но ORM и не обязательно, я не спорю, просто вот решил спросить, может добавили чего в ASP.NET MVC, а я и не заметил :).
Подавляющее большинство случаев это куча простеньких веб-сайтиков? ORM, как уже было сказано, вовсе не обязательный компонент, а БД - не единственный вариант data source. Тем более ту M, что есть в Django, многие бы с удовольствием заменили на SQLAlchemy или SQLObject - да вот блин косяк в том, что уж всё там больно удобно и ЦЕЛЬНО, и ORM не заменишь.
Модель - это не данные из базы, а модель предметной области. Фрейворк должен быть независим от способа проекции источника данных на модель. Особенно хорошо это видно при написании тестов, при Test-Driven Development. Для меня большой плюс то что в Microsoft не привязали фрейворк к какой-то своей технологии, LinqToSQL или Entity
Где я сказал, что это данные из базы? Мои слова - "Представление данных", и это не одно и то же. А вообще - заебли вы все (ikohut, вазилио, scala).
Не переживайте вы так. Всегда в сети найдутся люди, которые не согласны с вашей точкой зрения, менять ли при этом свой взгляд решать вам.
> просто вот решил спросить, может добавили чего в ASP.NET MVC.
Таким добавлением можно считать Entity Framework. Только это "новое" касается всего .NET, оно не привязано конкретно к MVC. Работать с данными в нем действительно легко. Поэтому, мне кажется, это можно считать именно тем, о чем вы спрашиваете, а то что оно распространяется на весь .NET минусом не является.
> просто вот решил спросить, может добавили чего в ASP.NET MVC.
Таким добавлением можно считать Entity Framework. Только это "новое" касается всего .NET, оно не привязано конкретно к MVC. Работать с данными в нем действительно легко. Поэтому, мне кажется, это можно считать именно тем, о чем вы спрашиваете, а то что оно распространяется на весь .NET минусом не является.
Хех, нет, речь шла именно о ДОСТУПЕ к данным, а не их представлении.
"А добавление, изменение, выборка (!) данных как происходит?" - ваш вопрос, к которому все мы (ikohut, вазилио, scala) апеллировали.
Если речь шла о модели - это вообще другое.
"А добавление, изменение, выборка (!) данных как происходит?" - ваш вопрос, к которому все мы (ikohut, вазилио, scala) апеллировали.
Если речь шла о модели - это вообще другое.
С удовольствием отвечу на вопросы по ASP.NET MVC. Сейчас разрабатываю проект с его использованием и могу поделиться опытом.
Спасибо за предложение. Я думаю вопросы будут, куда без них. :)
Если можно, расскажите как стыкуются компоненты (Grid, DataList, TreeView и т.д.) с ASP.NET MVC. А также есть ли возможность использовать ASP.NET AJAX с ASP.NET MVC.
Заранее благодарен за ответы.
Заранее благодарен за ответы.
Или от всех компонентов придется отказаться при использовании ASP.NET MVC и использовать только хелперы для генерирования html?
UFO just landed and posted this here
Тс-с-с-с! Только тихо! Поддержка WebFroms есть :)
а как же быть если нужно использовать более сложные компоненты, например telerik, devexpress и т.д.
Получается что им закрыт путь в ASP.NET MVC.
>>Разве сложно сделать ту же таблицу с нужными характеристиками и ячейками, а всю сортировку и методы\ссылки и остальное написать вообще не сложно
все это требует лишних трудозатрат. Хотелось бы использовать готовые и отлаженые решения...
Получается что им закрыт путь в ASP.NET MVC.
>>Разве сложно сделать ту же таблицу с нужными характеристиками и ячейками, а всю сортировку и методы\ссылки и остальное написать вообще не сложно
все это требует лишних трудозатрат. Хотелось бы использовать готовые и отлаженые решения...
Я уверен, что они появятся. Уже сейчас можно видеть наброски по ссылке в моем комментарии вам ниже.
UFO just landed and posted this here
Всем спасибо за ответы. Если кому будет интересно, нашел схожий вопрос на форуме телерика: Telerik and MVC
В общем-то, если сильно постараться, то можно разместить это на странице, но модель обработки событий и отсальные вещи совершенно разные. В любом случае это не путь MVC.
Для этой технологии уже разрабатываются свои Helper, которые будут иметь схожий функционал. Пример можно посмотреть в Code based ASP.NET MVC GridView
Касательно ASP.NET AJAX. Его можно использовать как библиотеку, но UpdatePanel и прочее уже отсутствует. Обновление страницы все равно прийдется писать вручную.
Для этой технологии уже разрабатываются свои Helper, которые будут иметь схожий функционал. Пример можно посмотреть в Code based ASP.NET MVC GridView
Касательно ASP.NET AJAX. Его можно использовать как библиотеку, но UpdatePanel и прочее уже отсутствует. Обновление страницы все равно прийдется писать вручную.
С интересом почитал. А Вы уже и сайты пишете на MVC? Я пока не рискую, только на домашней машине кручу.
Почему бы нет-то? Удобно очень. Наш набор технологий для сайтов построен на ASP.NET MVC (версии Preview 3 на данный момент).
Проблема будет, если идеология поменяется более-менее существенно. Пока в документации пишут: сделали так, но потом будем дописывать. Это смущает. :)
Ну и пока не понятно, как с аяксом стыковать.
Ну и пока не понятно, как с аяксом стыковать.
В ASP.NET MVC Preview 3 как раз появилась возможность "стыковать" контроллер с аяксом через JsonResult :)
Какие-то более менее крупные сайты я ещё не пишу на MVC. Этот достаточно мелкий, для знакомого. Поэтому меня тут никто не ограничивает, есть свой сервер, куда могу ставить и пре-релизы всяких библиотек. Так что тут я не переживаю. Если там все поменяется в релизе, то этот сайт за день можно будет переписать полностью. Хоть и на WebForms перебросить.
А с аяксом можно, например, с помощью сторонних библиотек, той же jQuery. Создать только нужно будет контроллер, который работает асинхронно и генерит на сервере нужный ответ.
Иделлогия не поменяется)
Сейчас, к Preview 3, на самом деле получше уже, хотя бы с механизмом Routes они закончили (MS это нужно было для другого проекта), сейчас не такие глобальные изменения ожидают, как раньше.
Однако, пока все сыровато, и мы много всего ждем, что еще не реализовано.
По поводу Аякса - а какая здесь вообще связь? MVC - архитектурный паттерн отделения различных видов логики от ее представления. Однако, есть так называемая логика представления, которая в данном случае может быть на клиенте (обычно у нас так и есть). Клиентская часть вполне может на своем уровне также реализовывать паттерн MVC для более удобного создания и поддержки продукта.
Реально же, можно использовать любую библиотеку из существующих, или создать свою, работающую с XMLHttpRequest, никакой разницы нет. Серверный MVC никак не связан с тем, как будет работать клиент. Однако, не будут работать старые контролы ASP.NET, использующие механизм обновления страницы с изменением состояния (postback). В том числе контролы, использующие MS ASP.NET AJAX.
Сейчас, к Preview 3, на самом деле получше уже, хотя бы с механизмом Routes они закончили (MS это нужно было для другого проекта), сейчас не такие глобальные изменения ожидают, как раньше.
Однако, пока все сыровато, и мы много всего ждем, что еще не реализовано.
По поводу Аякса - а какая здесь вообще связь? MVC - архитектурный паттерн отделения различных видов логики от ее представления. Однако, есть так называемая логика представления, которая в данном случае может быть на клиенте (обычно у нас так и есть). Клиентская часть вполне может на своем уровне также реализовывать паттерн MVC для более удобного создания и поддержки продукта.
Реально же, можно использовать любую библиотеку из существующих, или создать свою, работающую с XMLHttpRequest, никакой разницы нет. Серверный MVC никак не связан с тем, как будет работать клиент. Однако, не будут работать старые контролы ASP.NET, использующие механизм обновления страницы с изменением состояния (postback). В том числе контролы, использующие MS ASP.NET AJAX.
Говоря об аяксе, я имел в виду, что в классическом дотнете сейчас уже можно не сильно заморачиваться джаваскриптом — существует прозрачный высокоуровневый механизм в виде UpdatePanel.
И насколько я понимаю, UpdatePanel в MVC не работает.
Ну а ручками-то естественно всё можно, здесь даже вопросов не возникает.
И насколько я понимаю, UpdatePanel в MVC не работает.
Ну а ручками-то естественно всё можно, здесь даже вопросов не возникает.
Например, http://team23.ru (в частности сервис для Picasa по загрузке фотографий на Яндекс.Фотки) написан на ASP.NET MVC. Крутится, работает.
мощно написано... надо будет глубже изучить тему.
Drug'n'Drop
Надеюсь, что многие будут использовать именно эту реализацию MVC. Кстати, если кто-то уже использует, скажем, Castle MonoRail - ASP.NET MVC будет наполовину знакомым.
Мы используем подход Test-Driven Development и иже с ним, в свое время создали свой, более "тяжелый" вариант MVC, поэтому нам очень нравится то, что делают MS. Просто, открыто (наконец-то), легковесно.
Скорее бы релиз, а то большое количество инвестиций в технологии уходит на рефакторинг для обновляемых версий сторонних технологий, типа этого же ASP.NET MVC (особенно, когда вносятся критические изменения, так называемые breaking changes).
Мы используем подход Test-Driven Development и иже с ним, в свое время создали свой, более "тяжелый" вариант MVC, поэтому нам очень нравится то, что делают MS. Просто, открыто (наконец-то), легковесно.
Скорее бы релиз, а то большое количество инвестиций в технологии уходит на рефакторинг для обновляемых версий сторонних технологий, типа этого же ASP.NET MVC (особенно, когда вносятся критические изменения, так называемые breaking changes).
я думаю здесь вместе с nUnit вы сможете весь код так же тестировать. Тот же самый TDD получится. Castle хорошая штука, но у неё языки шаблонов мне не понравились - при верстке тяжелых вещей они становятся неподдерживаемыми. Здесь же удачно сделано.
И routes удачные. Короче, хорошо сделали.
И routes удачные. Короче, хорошо сделали.
А я и не говорю ничего против) Мы используем ASP.NET MVC с первого preview, NUnit и mbUnit используем уже бог весть сколько. Использовали ранее MonoRail - хорошая вещь, и свою писали.
Шаблоны - ранее использовали XSLT, но сейчас очень по душе пришлись шаблоны ASP.NET, которые по мнению многих хоть и напоминают "старый legacy ASP", где код был прямо в разметке, тем не менее очень функциональны. Проблема решилась тем, что в ASP не было принципов разделения кода (это значит, что "среди разметки" был также код для доступа к базе и SQL-запроосы, что - жесть), а MVC эту проблему решает и нисколько не смущает мешанина из HTML и C#, описывающего только логику представления.
Шаблоны - ранее использовали XSLT, но сейчас очень по душе пришлись шаблоны ASP.NET, которые по мнению многих хоть и напоминают "старый legacy ASP", где код был прямо в разметке, тем не менее очень функциональны. Проблема решилась тем, что в ASP не было принципов разделения кода (это значит, что "среди разметки" был также код для доступа к базе и SQL-запроосы, что - жесть), а MVC эту проблему решает и нисколько не смущает мешанина из HTML и C#, описывающего только логику представления.
Очень удобная вещь, тем более что она обеспечивает готовый MVC, так сказать, "от производителя".
Единственный "недостаток" этого фреймворка - необходимость все писать ручками. Забудьте о стандартных аспнетных контролах. Сообщество, конечно, уже трудится над реализацией библиотек, в которых будет некое подобие таковых, но это не панацея для тех, кто привык "драгать и дропать", а потом даблкликом фигачить евенты.
Лично меня это не напрягает совершенно, я и так предпочитаю все держать под контролем, а значит, ручками, ручками...
Единственный "недостаток" этого фреймворка - необходимость все писать ручками. Забудьте о стандартных аспнетных контролах. Сообщество, конечно, уже трудится над реализацией библиотек, в которых будет некое подобие таковых, но это не панацея для тех, кто привык "драгать и дропать", а потом даблкликом фигачить евенты.
Лично меня это не напрягает совершенно, я и так предпочитаю все держать под контролем, а значит, ручками, ручками...
Ну меня напрягло бы, т.к. это доп. инвестиции с позиции бизнесмена)
Но не напрягает потому, что я, как и MS, вижу в ASP.NET MVC не столько замену WebForms (у нас уже давно был свой MVC-framework, написанный на C#). И можно использовать всю мощь .NET. А для быстрого создания, я уверен, MS что-нибудь придумают.
Но не напрягает потому, что я, как и MS, вижу в ASP.NET MVC не столько замену WebForms (у нас уже давно был свой MVC-framework, написанный на C#). И можно использовать всю мощь .NET. А для быстрого создания, я уверен, MS что-нибудь придумают.
Не дописал мысль.
Вижу в ASP.NET MVC не столько замену WebForms, сколько грамотную реализацию так нужного нам MVC для создания систем с архитектурой REST, вместо введения состояний там, где даже протокол является "stateless" (без состояния, речь идет о протоколе http).
Вижу в ASP.NET MVC не столько замену WebForms, сколько грамотную реализацию так нужного нам MVC для создания систем с архитектурой REST, вместо введения состояний там, где даже протокол является "stateless" (без состояния, речь идет о протоколе http).
Сейчас же только Preview 3 доступна, ещё и релиза не было.
ASP.NET сейчас является технологией веб разработок, под которую написано больше всего компонент, тому поспособствовала сама архитектура. Я не думаю, что MVC это пропустит. Пусть не такое огромное количество будет доступно, но без поддержки точно не останемся.
ASP.NET сейчас является технологией веб разработок, под которую написано больше всего компонент, тому поспособствовала сама архитектура. Я не думаю, что MVC это пропустит. Пусть не такое огромное количество будет доступно, но без поддержки точно не останемся.
Про эту модель подробно узнал только сейчас, спасибо автору. Но вообще "изобрел" и применил я ей при написании первого сайта :) А MS реализация как всегда, мягко говоря не очень :\
Мне кажется, что "мягко говоря" плохо отзываться о каком-то продукте или разработке без обоснований некорректно. Есть негативный опыт? Поделитесь! Очень интересно узнать
Негативный опыт начинается со времен win95 и до сих пор, причем в последнее время от них я вижу все больше маркетинга и все меньше _рабочего_ кода, либо желание заработать на освоении новой _сложной_ технологии, которую конечно же "изобрели"(!!) мелкие и мягкие.
P.S. Я не противник Microsoft, и уважаю её за платформу .net, но количество "изобретений" на которых можно заработать меня просто поражает )
P.S. Я не противник Microsoft, и уважаю её за платформу .net, но количество "изобретений" на которых можно заработать меня просто поражает )
На дворе уже 2008 год! Конкретные претензии к ASP.NET MVC есть? Если есть, то еще не позно написать о них разработчикам ASP.NET MVC. Они активно прислушиваются к фитбекам пользователей.
1) В чем MVC нерабочий? Какие вещи вы бы в нем поправили? Сколько приложений на нем написали?
2) НИГДЕ не говорится, что MVC это изобретение MS. Это просто их реализация вполне распространенного подхода к написанию приложений.
3) Опять же, где вы здесь видите "заработать"? ASP.NET MVC совершенно бесплатен.
2) НИГДЕ не говорится, что MVC это изобретение MS. Это просто их реализация вполне распространенного подхода к написанию приложений.
3) Опять же, где вы здесь видите "заработать"? ASP.NET MVC совершенно бесплатен.
1. Я его не использовал.
2. Согласен.
3. Бесплатность не скрывает намерения заработать.
2. Согласен.
3. Бесплатность не скрывает намерения заработать.
Простите, влезу - ну вот не стоит отрицать, что Майкрософт не зарабатывает на этом - развивая ASP.NET MVC она способствует распространению ASP.NET среди разработчиков, а он требует инфраструктуру Майкрософта - Windows + IIS + MSSQL Server, а на продаже этих вещей Майкрософт и живет. То есть, чем больше разработчиков выбирает ASP.NET вместо PHP\Python\JSP\ЧтоТамЕще, тем больше ее доходы.
Если ваша реализация была лучше, давайте выкладывайте, будем её учить и статьи по ней писать. Я ведь не принципиален в этом, главное, чтобы платформа была хорошая. :)
Ещё и сравнительную табличку напишите, в чем ваше лучше MS, и в каких местах MS "как всегда".
Ещё и сравнительную табличку напишите, в чем ваше лучше MS, и в каких местах MS "как всегда".
Уже писал небольшой проект еще на первой публичной бете ASP.NET MVC, думаю скоро еще буду, т.к. штука классная и мощная. Статья, кстати очень хорошо написана, пишите еще.
Спасибо за хорошую статью!
Мое мнение - Решение для interprise уровня в лице asp.net впервые получило простые прелести, которыми разработчик на php/ruby/python мог пользоваться уже давно. Это очень хорошая новость.
Мое мнение - Решение для interprise уровня в лице asp.net впервые получило простые прелести, которыми разработчик на php/ruby/python мог пользоваться уже давно. Это очень хорошая новость.
Это случилось! Смерть порождениям извращенного разума: "состояния вида" и генерируемым JavaScrpt'ам!
С марта этого года работаю с ASP.NET MVC. Единственный минус в использовании текущих сборок, это то что нет обратной совместимости, с каждым новым Preview приходилось переделывать проекты =(.
Так же как и Maxmyd, предпочитаю держать все под контролем и ASP.NET MVC это позволяет делать.
Вот линки на блоги в которых есть полезная информация о использовании ASP.NET (все на английском языке):
1. ScottGu's Blog (для начинающих)
2. Scott Hanselman's Blog (для начинающих)
3. Phil Haack's Blog (продвинутых начинающих)
4. Stephen Walther's Blog
З.Ы. Как обзорная, данная статья отлично сделанa, но стоит сделать серию статей о ASP.NET MVC, в которой по отдельности рассказано о всех нюансах.
С марта этого года работаю с ASP.NET MVC. Единственный минус в использовании текущих сборок, это то что нет обратной совместимости, с каждым новым Preview приходилось переделывать проекты =(.
Так же как и Maxmyd, предпочитаю держать все под контролем и ASP.NET MVC это позволяет делать.
Вот линки на блоги в которых есть полезная информация о использовании ASP.NET (все на английском языке):
1. ScottGu's Blog (для начинающих)
2. Scott Hanselman's Blog (для начинающих)
3. Phil Haack's Blog (продвинутых начинающих)
4. Stephen Walther's Blog
З.Ы. Как обзорная, данная статья отлично сделанa, но стоит сделать серию статей о ASP.NET MVC, в которой по отдельности рассказано о всех нюансах.
теги не сработали =(
вот ссылки:
1. http://weblogs.asp.net/scottgu/archive/tags/MVC/default.aspx
2. http://www.hanselman.com/blog/CategoryView.aspx?category=ASP.NET+MVC
3.
a) http://haacked.com/Tags/ASP.NET%20MVC/default.aspx
b) http://haacked.com/Tags/aspnetmvc/default.aspx
4. http://weblogs.asp.net/stephenwalther/archive/tags/ASP.NET+MVC/default.aspx
вот ссылки:
1. http://weblogs.asp.net/scottgu/archive/tags/MVC/default.aspx
2. http://www.hanselman.com/blog/CategoryView.aspx?category=ASP.NET+MVC
3.
a) http://haacked.com/Tags/ASP.NET%20MVC/default.aspx
b) http://haacked.com/Tags/aspnetmvc/default.aspx
4. http://weblogs.asp.net/stephenwalther/archive/tags/ASP.NET+MVC/default.aspx
Спасибо за ссылки, у меня это уже давно в избранном, чего советую сделать и всем остальным. :)
По поводу "смерти", все же WebForms имеет свои преимущества. Никак нельзя говорить, что MVC пришел на смену WebForms.
По поводу "смерти", все же WebForms имеет свои преимущества. Никак нельзя говорить, что MVC пришел на смену WebForms.
Да, имеет свои преимущества их очень много: от скорости написания кода до его безопасности.
Но когда viewstate занимает на странице 13Kb (при этом он включён только для нужных элементов), а когда видишь размер JavaScript'ов сгенерируемых на простые валидаторы, шерсть встаёт дыбом, я молчу о скриптах которые прикрепляються AJAX элемнтам. Да я понимаю "всё" можно отключить, тщательно настроить, но при этом всём мы теряем в скорости написания кода.
Но когда viewstate занимает на странице 13Kb (при этом он включён только для нужных элементов), а когда видишь размер JavaScript'ов сгенерируемых на простые валидаторы, шерсть встаёт дыбом, я молчу о скриптах которые прикрепляються AJAX элемнтам. Да я понимаю "всё" можно отключить, тщательно настроить, но при этом всём мы теряем в скорости написания кода.
еще для заинтересованных в ASP.NET MVC рекоммендую обьязательно посмотреть на S#arp Architecture: ASP.NET MVC with NHibernate (http://www.codeplex.com/SharpArchitecture). Это пример приложения основаного на ASP.NET MVC + Spring + NHibernate
Приятно читать подобные статьи на хабре. Но разве бизнес логика должна хранится в модели? Модель это просто источник данных имхо, а бизес логика это отдельный слой, никак не входящий в модель.
Не очень проникся я данной технологией, может не понял всей прелести, но для меня асп имеет огромное приемущество перед php и остальными языками в том что не надо писать ничего руками. UpdatePanel, ListView и другие нововведения 2008 студии позволяют писать веб страницы с крутой поддержкой AJAX и без написания HTML кода вручную. Ни на что их не променяю :-)
Не очень проникся я данной технологией, может не понял всей прелести, но для меня асп имеет огромное приемущество перед php и остальными языками в том что не надо писать ничего руками. UpdatePanel, ListView и другие нововведения 2008 студии позволяют писать веб страницы с крутой поддержкой AJAX и без написания HTML кода вручную. Ни на что их не променяю :-)
Сейчас на работе пытаюсь использовать подход MVC при переводе живого проекта. Первая задача отделить бизнес объекты и логику.
Есть ряд проблем следующего плана. Допустим сейчас у меня есть такое разделение.
1. Модель это бизнес объект и имеет свои какие то проперти
2. Контролер это доступная логика по работе с бизнес – объектом (возрат списка объектов, добавление объекта и так далее )
Проблема возникает на этапе реализации котроллера для объектов, что имеют кучу хранимых процедур с параметрами. Например, хранимая процедура выбора с 5-6 параметрами, которые в свою очередь не всегда являются свойством объекта. Соответственно дописать в контролер их нельзя нарушает принцип MVC, c другой стороны мешает работать с уже наработанными хранимыми процедурами, что выполняют часть задач контролера. Есть один из выходов это дублирование логики хранимки на LINQ.
Есть ряд проблем следующего плана. Допустим сейчас у меня есть такое разделение.
1. Модель это бизнес объект и имеет свои какие то проперти
2. Контролер это доступная логика по работе с бизнес – объектом (возрат списка объектов, добавление объекта и так далее )
Проблема возникает на этапе реализации котроллера для объектов, что имеют кучу хранимых процедур с параметрами. Например, хранимая процедура выбора с 5-6 параметрами, которые в свою очередь не всегда являются свойством объекта. Соответственно дописать в контролер их нельзя нарушает принцип MVC, c другой стороны мешает работать с уже наработанными хранимыми процедурами, что выполняют часть задач контролера. Есть один из выходов это дублирование логики хранимки на LINQ.
А какие это параметры, можете пример привести?
Почему Controller должен оперировать в качестве параметра только с свойствами объекта вашей модели?
Почему Controller должен оперировать в качестве параметра только с свойствами объекта вашей модели?
Думаю вам следует внимательно еще раз прочитать этот пост. Контроллер отвечает за обработку запросов пользователя, но НЕ ЗА СОХРАНЕНИЕ ДАННЫХ В БАЗУ. За это должна отвечать модель. Все это прекрасно объяснено в данном посте.
Всё это, конечно, интересно и замечательно, но ничего нового... Насколько мне известно, MS уже давно предлагает разделять проект на три составляющие, а именно:
DAL (Data Access Layer) работа непосредственно с базами данных или любой другой информацией
BLL (Bussiness Logic Layer) логика, обработка информации
PL/UI (Presentation Layer / User Interface) сбор информации и вывод информации
Как бы так... Более подробно и на английском языке - www.asp.net
А введение новой фичи - структуры MVC - по-моему, это ничто иное, как следование модным тенденциям, не более, хотя надо признать, что сам принцип MVC очень хорош, но опять же повторюсь - ничего нового.
DAL (Data Access Layer) работа непосредственно с базами данных или любой другой информацией
BLL (Bussiness Logic Layer) логика, обработка информации
PL/UI (Presentation Layer / User Interface) сбор информации и вывод информации
Как бы так... Более подробно и на английском языке - www.asp.net
А введение новой фичи - структуры MVC - по-моему, это ничто иное, как следование модным тенденциям, не более, хотя надо признать, что сам принцип MVC очень хорош, но опять же повторюсь - ничего нового.
# <link href=<'%= AppHelper.CssUrl(Site.css) %'> rel='stylesheet' type='text/css' />
Всето такого вроде можно написать так
# link href'=~/css/Site.css' runat='server' rel='stylesheet' type='text/css'
Если память меня не подводит.
Аналогично для картинок. Не забываая про runat=server
Всето такого вроде можно написать так
# link href'=~/css/Site.css' runat='server' rel='stylesheet' type='text/css'
Если память меня не подводит.
Аналогично для картинок. Не забываая про runat=server
Можно и так, но, по идее, так должно немного "тяжелее" работать.
Господа, ваш спор бессмысленен. =) CSS и .SKIN файлы надо хранить в App_Themes, иначе его не подхватит вьюстейт и после посбека не отрисует контролы.
C CSS я попробовал, все работает, но в MVC не является хорошей практикой использовать runat=server.
А, простите, о каких Viewstate и Postback вы говорите? :)))
А, простите, о каких Viewstate и Postback вы говорите? :)))
Оно работает, но не всегда. Попробуй сделать два связанных контрола, например textbox и gridview, причем грид должен затягивать данные в зависимости от значения текстового поля (можно дату туда писать, или число строк в гриде, все равно). Когда ты выполнишь постбек страницы и грид отрисует новые значения, стили исчезнут (хотя в head страници ссылка на .css будет правильная).
Я к тому, что в MVC нет таких понятий уже как постбек и грид.
Вы их или напильником туда прикрутили, что возможно, или говорите просто о WebForms.
Вы их или напильником туда прикрутили, что возможно, или говорите просто о WebForms.
Ну да, я про традиционный подход и webforms, MVC пока только концепт-кар. Неизвестно, приживется ли вообще такая идея. Ведь фактически "" - это возвращение к ASP. Я читал про эту штуку уже давно, но в свое время неоднозначность решений вызвала большие дебаты.
Не совсем возвращение, различия в том, что в лкассическом ASP код представления был смешан с кодом логики, работы с данными и т.д. В View если и используется C#, то только для программирования представления.
Идея прижилась уже давно, в других платформах, ASP.NET MVC просто реализация от MS.
Идея прижилась уже давно, в других платформах, ASP.NET MVC просто реализация от MS.
Не от MS. MVC - это проект сторонних энтузиастов, который MS взяли под свое крыло. И один момент лично меня в нем настораживает.
Разработка asp велась эволюционно, т.е. изменения были последовательными. А MVC разом меняет концепцию. Например, отказываются от общего form-элемента, поощряют разрывы, от которых уже вроде бы отказались. Такой проект будет сложным для поддержки, каждому, кто с ним работает, а особенно будет работать после того, как основная команда выполнит свою работу и уйдет из компании, придется вникать в тонкости реализации этого подхода (причем, далеко не очевидного и не основного для asp.net разработчиков).
В общем, я не знаю, станет ли внедрение MVC массовой практикой.
Разработка asp велась эволюционно, т.е. изменения были последовательными. А MVC разом меняет концепцию. Например, отказываются от общего form-элемента, поощряют разрывы, от которых уже вроде бы отказались. Такой проект будет сложным для поддержки, каждому, кто с ним работает, а особенно будет работать после того, как основная команда выполнит свою работу и уйдет из компании, придется вникать в тонкости реализации этого подхода (причем, далеко не очевидного и не основного для asp.net разработчиков).
В общем, я не знаю, станет ли внедрение MVC массовой практикой.
Я о чем писал, MVC это уже массовая технология. Взять тот же Ruby on Rails. Полностью по этой концепции реализован. Существуют ещё фреймворки под PHP и т.д. Просто это ново для ASP.NET разработчиков.
>> А введение новой фичи - структуры MVC - по-моему, это ничто иное, как следование модным тенденциям,
Это вы серьезно не писали на ASP.NET :) Тестировать код было практически невозможно. Прогресс на лицо!
Это вы серьезно не писали на ASP.NET :) Тестировать код было практически невозможно. Прогресс на лицо!
Работаю в очень крупной организации, заказчики не менее серьёзные. Все проекты организованы так, как я описал... Без MVC. И ничего, всё протестировано, всё работает. Вы как бы, видимо, не до конца поняли моё сообщение, перечитайте, если не затруднит.
На сколько я могу судить из собственного опыта, тестирование логики работы ASP.NET старниц с помощью юнит тестов - это то еще извращение. А MVC позволяет писать тесты для контроллеров и тестировать работу приложения кодом, а не руками. ТАк что для меня MVC - это не модная тенденция, а отличный способ писать код более умно и качественно
Стоп. Зачем тестировать логику работы asp.net страниц? Это примерно то же самое, что тестировать Views-ы в MVC. А контроллеры в MVC = BLL. BLL в данном случае класс (или классы) с методами, которые отвечают за обработку информации (клик юзера на кнопку - тоже информация).
Простой пример - на страничке есть кнопка регистрации. Юзер по ней щёлкнул, случился event - reg_button_click... перекидываем на страницу регистрации, там формочка для ввода необходимых данных, и кнопочка "завершить регистрацию". Так event нажатия этой кнопки вызывает метод register_user(данные из формочки). Метод register_user(данные) - метод класса(-ов), отвечающего за бизнес логику. Сам метод register_user(данные) дальше вызывает метод(-ы) DAL-а - отвечающие за общение с базой данных (или любыми другими хранителями информации)... Как-то так (думаю, что суть ясна). Так вот протестировать с помощью юнит-тестинга очень просто как методы BLL-а, так и DAL-а...
Ещё раз - я сам против того, чтобы всю программу (веб-приложение) запихивать в event-ы формочек - это и правда глупо, но я пока не вижу значительных нововведений, т.к. по сути DAL+BLL+PL/UI = MVC.
Простой пример - на страничке есть кнопка регистрации. Юзер по ней щёлкнул, случился event - reg_button_click... перекидываем на страницу регистрации, там формочка для ввода необходимых данных, и кнопочка "завершить регистрацию". Так event нажатия этой кнопки вызывает метод register_user(данные из формочки). Метод register_user(данные) - метод класса(-ов), отвечающего за бизнес логику. Сам метод register_user(данные) дальше вызывает метод(-ы) DAL-а - отвечающие за общение с базой данных (или любыми другими хранителями информации)... Как-то так (думаю, что суть ясна). Так вот протестировать с помощью юнит-тестинга очень просто как методы BLL-а, так и DAL-а...
Ещё раз - я сам против того, чтобы всю программу (веб-приложение) запихивать в event-ы формочек - это и правда глупо, но я пока не вижу значительных нововведений, т.к. по сути DAL+BLL+PL/UI = MVC.
Так как раз логика работы этой кнопочки - это и есть самое главное, так именно ее "дергает" пользователь. Кроме того не вся логика в BLL и DAL.
Понял, к чему вы клоните. Ну, насчёт тестирования UI - это вообще достаточно сложная и проблемная часть, однако не вижу, чем MVC решает эту проблему. Честно говоря, в чистом виде с MVC столкнулся в рельсах - надо сказать, что для меня многие вещи остались непрозрачными и не до конца понятными.
Та логика, которая находится в event handler-ах уж слишком примитивна. Не уверен, что там могут возникнуть серьёзные проблемы.
Пока что не стал бы спешить переходить на ASP.NET MVC, возможно в будущем...
Та логика, которая находится в event handler-ах уж слишком примитивна. Не уверен, что там могут возникнуть серьёзные проблемы.
Пока что не стал бы спешить переходить на ASP.NET MVC, возможно в будущем...
Нельзя забывать, что логика работы UI - это тоже логика.
А во-вторых, BLL - это часть модели, а не "контроллеры в MVC". Модель можно переиспользовать в любой другой среде, где этих контроллеров не будет, а контроллеры специфичны для приложения (поэтому и являются логикой приложения в MVC). Логика же работы UI никак не связана именно с этим MVC, о котором идет речь в сабже. Как делить данные и способы работы с ним на уровне UI - другой вопрос. В частности, там может быть своя реализация MVC (Что-то типа UI-MVC, но она никак не будет связана с MVC архитектуры приложения). И именно UI отвечает за обработку кликов и так далее, а контроллеры отвечают за правильное принятие данных с клиента (не обработать клик, а уже получить данные - это важно), которые далее передаются в модель на обработку (ибо, именно там вся бизнес-логика).
Мы, например, используем ASP.NET MVC для реализации REST-ful веб-сервисов.
А во-вторых, BLL - это часть модели, а не "контроллеры в MVC". Модель можно переиспользовать в любой другой среде, где этих контроллеров не будет, а контроллеры специфичны для приложения (поэтому и являются логикой приложения в MVC). Логика же работы UI никак не связана именно с этим MVC, о котором идет речь в сабже. Как делить данные и способы работы с ним на уровне UI - другой вопрос. В частности, там может быть своя реализация MVC (Что-то типа UI-MVC, но она никак не будет связана с MVC архитектуры приложения). И именно UI отвечает за обработку кликов и так далее, а контроллеры отвечают за правильное принятие данных с клиента (не обработать клик, а уже получить данные - это важно), которые далее передаются в модель на обработку (ибо, именно там вся бизнес-логика).
Мы, например, используем ASP.NET MVC для реализации REST-ful веб-сервисов.
только не забваем, что юнит проджекты только в студии professional :(
Фантастика! Уже пятьдесят комментариев и ни один не обратил внимания на авторский текст с точки зрения простейших правил орфографии и стилистики русского языка.
Автор, Вы, вообще говоря, в школе учились? Быть программистом абсолютно не отменяет нужности и полезности знаний обычного русского языка!
Считаю, что каким бы трепетным не было Ваше отношение к шаблону MVC, подобное невежество на данном ресурсе недопустимо. Дальше первого абзаца просто невозможно читать!
А теперь вопрос по сути. Вы лишь "играетесь" со связкой MVC + LINQ, или занимаетесь этим в коммерческих целях? Во втором случае попрошу Вас обрисовать возможности кэширования SQL в Ваших приложениях. Как Вы с этим справляетесь?
Автор, Вы, вообще говоря, в школе учились? Быть программистом абсолютно не отменяет нужности и полезности знаний обычного русского языка!
Считаю, что каким бы трепетным не было Ваше отношение к шаблону MVC, подобное невежество на данном ресурсе недопустимо. Дальше первого абзаца просто невозможно читать!
А теперь вопрос по сути. Вы лишь "играетесь" со связкой MVC + LINQ, или занимаетесь этим в коммерческих целях? Во втором случае попрошу Вас обрисовать возможности кэширования SQL в Ваших приложениях. Как Вы с этим справляетесь?
Те, что нашел сразу, по большей части опечатки. Я статью эту писал в 5 утра, не спалось, и средства проверки орфографии под рукой не было. Может людям больше интересен смысл, если ещё никто об этом не написал?
Хорошо, что вы к сути все же перешли. Чем отличается кеширование в MVC+LINQ от любого другого кеширования? Вызывайте от вашего запроса ToList(). Это выполнит запрос к вашей БД именно в этот момент и вернет список объектов, его лекго можете кешировать как вам удобно.
Ещё одним из вариантов повышения производительности может стать хранение DataContext единого для всего приложения, но использовать его только для чтения данных. Изменения лучше делать "локальным" контекстом, чтобы объемы памяти, занимаемые приложением, не росли.
Школу с отличием закончил.
Хорошо, что вы к сути все же перешли. Чем отличается кеширование в MVC+LINQ от любого другого кеширования? Вызывайте от вашего запроса ToList(). Это выполнит запрос к вашей БД именно в этот момент и вернет список объектов, его лекго можете кешировать как вам удобно.
Ещё одним из вариантов повышения производительности может стать хранение DataContext единого для всего приложения, но использовать его только для чтения данных. Изменения лучше делать "локальным" контекстом, чтобы объемы памяти, занимаемые приложением, не росли.
Школу с отличием закончил.
Я наверно не совсем корректно выразился. Вам знаком класс SqlCacheDependency? Очевидно, что никакого подобного механизма использовать совместно с LINQ не удастся. Кроме того, очевидно, что создание собственного конвейера кэширования никто и никогда не отменит, однако это довольно трудоемкое занятие.
В этом и вопрос, я хотел узнать, как Вы конкретно "разруливаете" эту ситуацию.
В этом и вопрос, я хотел узнать, как Вы конкретно "разруливаете" эту ситуацию.
*вспомнил учительницу по русскому языку* О_О
PS: Не нравиться как написана статья – идите читайте ЖЖ.
PPS: А запятую пропустили. Лингвист вы наш. :)
PS: Не нравиться как написана статья – идите читайте ЖЖ.
PPS: А запятую пропустили. Лингвист вы наш. :)
"пути к директориям и сзображениями и css файлами" - поправьте ошибочку
В минувшем сезоне данная дема освещалась в рамках запуска Visual Studio 2008.
Кому интересна тема, доступны презентация и видео - http://www.microsoft.com/rus/msdn/events…
Кому интересна тема, доступны презентация и видео - http://www.microsoft.com/rus/msdn/events…
Спасибо!
Спасибо!
Это чертовски приятно. Очень не хватало рельсов для .Net
Статья супер! Не слушай тех, кто критикует. Многие из них не то что MVC но и значение ООП не понимают :)
Люблю цивилизацию первую. Одной из основных вех в строительстве цивилизации является разработка железной дороги. Помочь брацкому народу можно ежели чего как в военном так и в экономическом плане. Вообщем круть! Ах да, MVC...
MVC по значимости можно сравнить с железной дорогой. На основе этого паттерна построено и надстроено уже куева туча фреймворков. Struts, Spring MVC, Tapestry, JSF, ни одно мало-мальски серьезное java приложение не обходится без подобной основы. И так уже лет 5. А тут вот узнаю, что в .net это ацкое нововведение, и "Команда Microsoft очень интенсивно развивает свои продукты и средства для разработчиков". Ну что можно сказать. Спасибо конечно, что пронесли свою девственную самобытность сквозь года, устояв на отшибе времени пред лицом искушения и соблазнов. Но как то смысла в этом наверное не много.
Программист, если у тебя подобная новость вызывает душераздирающий восторг и в горле першит от радости, задумайся, действительно ли ты хочешь связать свою жизнь с технологией, которая тщательно обходит стороной весь прогрессивный мир? В отличае от забитой цивилизации у тебя все еще есть выбор.
Не корысти ради речь веду а во благо, минусы не приветствуются...
Ну и статья вцелом нормал.
MVC по значимости можно сравнить с железной дорогой. На основе этого паттерна построено и надстроено уже куева туча фреймворков. Struts, Spring MVC, Tapestry, JSF, ни одно мало-мальски серьезное java приложение не обходится без подобной основы. И так уже лет 5. А тут вот узнаю, что в .net это ацкое нововведение, и "Команда Microsoft очень интенсивно развивает свои продукты и средства для разработчиков". Ну что можно сказать. Спасибо конечно, что пронесли свою девственную самобытность сквозь года, устояв на отшибе времени пред лицом искушения и соблазнов. Но как то смысла в этом наверное не много.
Программист, если у тебя подобная новость вызывает душераздирающий восторг и в горле першит от радости, задумайся, действительно ли ты хочешь связать свою жизнь с технологией, которая тщательно обходит стороной весь прогрессивный мир? В отличае от забитой цивилизации у тебя все еще есть выбор.
Не корысти ради речь веду а во благо, минусы не приветствуются...
Ну и статья вцелом нормал.
Комментарий располагающий к развернутому ответу :)
Для начала, что вас натолкнуло на мысль о "самобытности на отшибе времени"? Я писал статью в контексте продуктов MS, да, я ними пользуюсь. С другими знаком просто для общего развития, но совсем не глубоко. Если на Java ни одно крупное приложение не делается без MVC, неужели это её такой плюс? Как же построены крупные ASP.NET сайты? Вы сами знакомы с ASP.NET WebForms? Какие ещё технологии предлагают подобное в веб разработках? Что может быть лучше для интранет сайтов?
Не совсем понимаю опять же вашу позицию. Не MVC единым живет веб разработка. У меня и без него выходило строить вполне нормальные сайты. Если вы читали комментарии, то многие сказали нафиг-нафиг, будем дальше на веб формах, так как они дают много всего, что упрощает жизнь. Выбор у меня есть и я в своем насегодня отнюдь не разочарован. Если в татье как-то и получилось рассказать об MVC без глубин истории или может кому показалось, что я это преподнес как нововведение во _всем_ программерском мире, то уж сори, не специально и не надо так самому близко к сердцу принимать.
Вы сами-то с какими технологиями последнее время работаете? Я почему-то уверен, что по ASP.NET вы вот пару таких статей прочитали, и сделали для себя вывод, что фигня. Может тут я ошибаюсь. Я ведь сужу только по одному комментарию. Хотя вы описали мое поведение, как буд-то рядом сидели и наблюдали "восторг и першение в горле от радости".
Технологии MS это не панацея от всех проблем, конечно. Но называть её "обходящей весь прогрессивный мир" по меньшей мере глупо.
Минус вам поправил, а то кто-то уже постарался.
За оценку статьи спасибо.
Для начала, что вас натолкнуло на мысль о "самобытности на отшибе времени"? Я писал статью в контексте продуктов MS, да, я ними пользуюсь. С другими знаком просто для общего развития, но совсем не глубоко. Если на Java ни одно крупное приложение не делается без MVC, неужели это её такой плюс? Как же построены крупные ASP.NET сайты? Вы сами знакомы с ASP.NET WebForms? Какие ещё технологии предлагают подобное в веб разработках? Что может быть лучше для интранет сайтов?
Не совсем понимаю опять же вашу позицию. Не MVC единым живет веб разработка. У меня и без него выходило строить вполне нормальные сайты. Если вы читали комментарии, то многие сказали нафиг-нафиг, будем дальше на веб формах, так как они дают много всего, что упрощает жизнь. Выбор у меня есть и я в своем насегодня отнюдь не разочарован. Если в татье как-то и получилось рассказать об MVC без глубин истории или может кому показалось, что я это преподнес как нововведение во _всем_ программерском мире, то уж сори, не специально и не надо так самому близко к сердцу принимать.
Вы сами-то с какими технологиями последнее время работаете? Я почему-то уверен, что по ASP.NET вы вот пару таких статей прочитали, и сделали для себя вывод, что фигня. Может тут я ошибаюсь. Я ведь сужу только по одному комментарию. Хотя вы описали мое поведение, как буд-то рядом сидели и наблюдали "восторг и першение в горле от радости".
Технологии MS это не панацея от всех проблем, конечно. Но называть её "обходящей весь прогрессивный мир" по меньшей мере глупо.
Минус вам поправил, а то кто-то уже постарался.
За оценку статьи спасибо.
Вы правы, с .net опыта у меня совсем не много. Тут речь о другом, о паттерне, который применим практически к любому языку и технологии. Меня просто удивило, что этот фундаментальный камень, на основе которого часто строися базис приложения, остался неизвестным такому широкому кругу программистов. И его только начинают популяризировать в среде Microsoft. WebForms по сути очень похож на JSF, ну или наоборот. Это похоже на компоненты относящиеся к View. Если начать нагружать в них бизнес логику, без использования MVC, это приведет к проблеммам с поддержкой и повторным использованием этих самых компонентов. Как результат - Copy-Paste, и вскорости замыкаем круг с поддержкой и реюзабилити. Многие проблемы подобного характера просто незаметны в настоящий момент, поэтому продолжают писаться программы без использованния шаблонов и MVC в часности.
Вообщем все это лирика, в конце концов все сводится к тому, что в голове у того, кто пишет код или проектирует систему.
Вообщем все это лирика, в конце концов все сводится к тому, что в голове у того, кто пишет код или проектирует систему.
Технология MVC - НАМНОГО старше. Первыми ее приминили в Smalltalk, так что подсчитайте....
Между прочим вы вообще знаете назначение этой технологиии? Ведь ВЕСЬ прогрессивный мир тянеться к этой технологии ибо, лутше пока ничего не придумали. (Для серьезных и крупных программ)
PS: "куева туча фреймворков" написанна не просто так.
Между прочим вы вообще знаете назначение этой технологиии? Ведь ВЕСЬ прогрессивный мир тянеться к этой технологии ибо, лутше пока ничего не придумали. (Для серьезных и крупных программ)
PS: "куева туча фреймворков" написанна не просто так.
Не пойму почему паттерн MVC не используется в WebForms? Ведь разметка страницы - это View, код-бихайнд - Controller, а бизнес-логика - это Model. Проблем с URL-Rewriting'ом не встречал. Проблем с тестированием Controller'а и Model в WebForms нет. Это объекты классов - бери да тестируй. Что касается тестирование интерфейса, то тут и у "ASP.NET MVC" нет решения, особенно, если учесть необходимость кросс-браузерного тестирования - все равно придется использовать сторонние разработки.
С одной стороны так и есть и вы все говорите правильно. Но в веб формах класс представления, наследуется от контроллера. Т.е. между ними связи довольно таки жесткие и не такие как в оригинальном паттерне MVC. К тому же слой представления в веб формах "черезчур" умный. Да и весь паттерн идет лесом, когда мы добавляем SqlDataSource на страницу. Это ведь уже никак не вписывается в нужный паттерн. А WebForms это позволяют делать вполне легко и даже способствуют этому.
В общем-то проблем с URL-Rewiting нету, но его приходится самому писать :) , либо пользоваться сторонними средствами. В ASP.NET MVC роутеры уже заложены в основу.
Насчет тестирования пусть кто-то другой, напирмер,
VasilioRuzanni
Насчет кросс-бараузерного тестирования даже не знаю что сказать. Вы какие сторонние разработки используете для этого, кроме самих "сторонних" браузеров?
В общем-то проблем с URL-Rewiting нету, но его приходится самому писать :) , либо пользоваться сторонними средствами. В ASP.NET MVC роутеры уже заложены в основу.
Насчет тестирования пусть кто-то другой, напирмер,
VasilioRuzanniНасчет кросс-бараузерного тестирования даже не знаю что сказать. Вы какие сторонние разработки используете для этого, кроме самих "сторонних" браузеров?
Слой представления в веб-формах будет на столько умным на сколько его сделать умным. SqlDataSource ни разу на страницу не добавлял :)
Для кросс-браузерного тестирования я еще ничего не использовал толком. Погонял слегка Selenium IDE в виде плагина для FF, но у них есть и серверная часть для кросс-браузерного тестирования. Еще вот нашел довольно быстро - поддерживает IE и FF, а скоро и сафари под вин (можно сразу жать на Watch Demo).
Для кросс-браузерного тестирования я еще ничего не использовал толком. Погонял слегка Selenium IDE в виде плагина для FF, но у них есть и серверная часть для кросс-браузерного тестирования. Еще вот нашел довольно быстро - поддерживает IE и FF, а скоро и сафари под вин (можно сразу жать на Watch Demo).
Sql я тоже нет, а вот ObjectDataSource, довольно часто. Просто смысла нет переписывать его функционал в Code Behind. И получается вроде все и отделено, но контроллер уже переместился полностью во View. Причем если с SqlDataSource можно и не согласиться, сам виже его полезным так, только может для тестирования, чтобы можно было побыстропу получить данные откуда-то, то ObjectDataSource в концепции WebForms очень хороший инструмент.
Поэтому, для того чтобы все в WebForms сделать по идеологии MVC нужно полностью отказаться от всех прелестей WebForms.
За ссылки спасибо, сразу не понял о чем вы. Чем-то подобным уже пользовался, только не помню точно чем. Давно было. По моему что-то из тулзов MS.
Поэтому, для того чтобы все в WebForms сделать по идеологии MVC нужно полностью отказаться от всех прелестей WebForms.
За ссылки спасибо, сразу не понял о чем вы. Чем-то подобным уже пользовался, только не помню точно чем. Давно было. По моему что-то из тулзов MS.
Вот еще неплохой материал по МVC:
Обобщенный Model-View-Controller - Примеры на Java SWT & WinForms (C#)
Model-View-Controller в .Net
Обобщенный Model-View-Controller - Примеры на Java SWT & WinForms (C#)
Model-View-Controller в .Net
Почему-то Хабр не распознал теги..
Обобщенный Model-View-Controller - Примеры на Java SWT & WinForms (C#):
http://rsdn.ru/article/patterns/generic-mvc.xml
Model-View-Controller в .Net:
http://rsdn.ru/article/patterns/ModelViewPresenter.xml
Обобщенный Model-View-Controller - Примеры на Java SWT & WinForms (C#):
http://rsdn.ru/article/patterns/generic-mvc.xml
Model-View-Controller в .Net:
http://rsdn.ru/article/patterns/ModelViewPresenter.xml
Спасибо. Первая ссылка доступна из вики, на которую я сослался в статье.
Тут конечно об MVC в целом говорится, а не о ASP.NET MVC. Но для общего развития тоже будет полезным.
Тут конечно об MVC в целом говорится, а не о ASP.NET MVC. Но для общего развития тоже будет полезным.
Я столкнулся с MVC именно в WinForms. Как известно, там трудно четко разбить проект на 3 состаляющие, поэтому приходиться использовать различные паттерны типа Observer и др. Тоесть нет однозначного подхода к решению.
ИМХО Было бы неплохо сделать одельный раздел посвященый паттернам проектирования. Может народ и стал бы их чаще использовать :)
ИМХО Было бы неплохо сделать одельный раздел посвященый паттернам проектирования. Может народ и стал бы их чаще использовать :)
C WinForms как-то мало приходилось работать, поэтому ничего тут не скажу.
Паттерны это очень круто, действительно. Но чтобы это было полезно, нужно на реальном проекте показывать. В данном случае, правда, статья больше об ASP.NET MVC как технологии, чем о фреймворке в общем. А то паттерны много читать и изучать можно, но с какого боку их реально прикрутить к проекту не всегда понятно.
Паттерны это очень круто, действительно. Но чтобы это было полезно, нужно на реальном проекте показывать. В данном случае, правда, статья больше об ASP.NET MVC как технологии, чем о фреймворке в общем. А то паттерны много читать и изучать можно, но с какого боку их реально прикрутить к проекту не всегда понятно.
Подскажите, а как в ASP.NET MVC сделать так чтобы контроллер начал срабатывать на открытие корня сайта ? default.aspx или /
На default.aspx думаю особо смысла нету делать, а на корень не получилось настроить. А почему вам это принципиально?
UFO just landed and posted this here
=)
UFO just landed and posted this here
Sign up to leave a comment.
ASP.NET MVC на реальном примере. Теория и вступление.