Comments 18
аа спасибо )))
Я в шоке.
Я боюсь спросить: а существует ли способ в Asp.NET MVC вывести список кастомным html-шаблоном, при этом написав менее 100 строк кода?
Я боюсь спросить: а существует ли способ в Asp.NET MVC вывести список кастомным html-шаблоном, при этом написав менее 100 строк кода?
Вы вынесли мне мозг:(
Что мешает доработать способ 3, сделав умную модель для вью, которая достает все нужные списки в конструкторе? И код не будет перегружен лишними конструкциями, и извращаться никак не надо.
Что мешает доработать способ 3, сделав умную модель для вью, которая достает все нужные списки в конструкторе? И код не будет перегружен лишними конструкциями, и извращаться никак не надо.
Отлично, это шестой способ!
Здесь один тонкий момент. Обязательно найдутся разработчики, которые назовут извращением именно Ваш способ. Например, согласно Догме 1, модель пассивна, а все действия совершает контроллер. А согласно Догме 2, модель не имеет права «знать» о доступе к данным.
Но суть не в том, чтобы не извращаться, а в том, чтобы накидать побольше способов, и чтобы каждый обрадовался хоть одному из них.
Здесь один тонкий момент. Обязательно найдутся разработчики, которые назовут извращением именно Ваш способ. Например, согласно Догме 1, модель пассивна, а все действия совершает контроллер. А согласно Догме 2, модель не имеет права «знать» о доступе к данным.
Но суть не в том, чтобы не извращаться, а в том, чтобы накидать побольше способов, и чтобы каждый обрадовался хоть одному из них.
Если так хочется следовать всем догмам, можно сделать метод CreateViewModel(...) который будет в одном месте конструировать пассивную модель.
«накидать побольше способов, и чтобы каждый обрадовался хоть одному из них»
На мой взгляд, как раз это один из концептуальных недостатков и самого ASP.NET MVC. Он, в отличие от Rails, не задает какого-то определенного, «правильного» способа, что заставляет каждого изобретать велосипеды по ходу работы.
Ему не помешало бы быть более «Opinionated».
А что за догмы?
На мой взгляд, как раз это один из концептуальных недостатков и самого ASP.NET MVC. Он, в отличие от Rails, не задает какого-то определенного, «правильного» способа, что заставляет каждого изобретать велосипеды по ходу работы.
Ему не помешало бы быть более «Opinionated».
А что за догмы?
Догмы — это, как раз, «правильный» способ. Заглянем к Фаулеру и сделаем, как у него написано.
Но ведь у нас разные ситуации. Где-то больше подходит DDD или там CQRS всякое. Где-то DLINQ — и готово! Все вокруг, как правило, борются за «как надо», а я вот решил с пеной у рта доказывать всем, что можно по-разному. Тут все взрослые, каждый сам выберет себе, как ему (и всем на свете) надо.
Но ведь у нас разные ситуации. Где-то больше подходит DDD или там CQRS всякое. Где-то DLINQ — и готово! Все вокруг, как правило, борются за «как надо», а я вот решил с пеной у рта доказывать всем, что можно по-разному. Тут все взрослые, каждый сам выберет себе, как ему (и всем на свете) надо.
С этим не поспоришь. Я немного другое имел в виду, но тут спорить не о чем.
Просто все же есть какой-то наиболее «правильный способ» и для меня это Thunderdome Principle. По сути, как раз некие догмы. Никто не ограничивает воображение, но если есть хороший (или даже очевидно лучший) способ сделать что-то — на мой взгляд стоит того, чтобы внести во фреймворк как способ по-умолчанию, и чтобы упростить его использование, всюду следовать принципу Convention over Configuration.
Вы ведь и сами понимаете, что такие способы как The Bad and The Ugly — это скорее «технические возможности», и что-то мне подсказывает, что сами вы их применять не будете даже для «простой формы с одним списком» :) А используете вариант SuperSmart, да еще и в нем, чтоб избавиться от Magic Strings, используете T4MVC, чтоб совсем хорошо стало. Вот и получается, что хороший способ, может и не самый простой, и, хотя и не исключает вариантов, все же, достаточно определенный.
Просто все же есть какой-то наиболее «правильный способ» и для меня это Thunderdome Principle. По сути, как раз некие догмы. Никто не ограничивает воображение, но если есть хороший (или даже очевидно лучший) способ сделать что-то — на мой взгляд стоит того, чтобы внести во фреймворк как способ по-умолчанию, и чтобы упростить его использование, всюду следовать принципу Convention over Configuration.
Вы ведь и сами понимаете, что такие способы как The Bad and The Ugly — это скорее «технические возможности», и что-то мне подсказывает, что сами вы их применять не будете даже для «простой формы с одним списком» :) А используете вариант SuperSmart, да еще и в нем, чтоб избавиться от Magic Strings, используете T4MVC, чтоб совсем хорошо стало. Вот и получается, что хороший способ, может и не самый простой, и, хотя и не исключает вариантов, все же, достаточно определенный.
Я думаю, это не хороший способ, а просто у нас просто одинаковые вкусы:) Мне кажется, тут все как с музыкой. Вот слушаешь [...], и кажется, ну вот — настоящий шедевр, и только идиоты с испорченным вкусом этого не понимают. А уж мы-то, настоящие ценители, знаем толк!
Я бы назвал «лучшим» способ, который дает максимальную производительность и максимальное наслаждение (или, хотя бы, чувство удовлетворения) вот этому конкретному разработчику в этой конкретной ситуации.
Например, меня все больше напрягает официально признанный convention о том, что все View должны лежать в одноименной папке.
Я бы назвал «лучшим» способ, который дает максимальную производительность и максимальное наслаждение (или, хотя бы, чувство удовлетворения) вот этому конкретному разработчику в этой конкретной ситуации.
Например, меня все больше напрягает официально признанный convention о том, что все View должны лежать в одноименной папке.
Я тут, пожалуй, соглашусь. ASP.NET MVC по определению не может быть направленным в определенное русло (opinionated), каждый строит на нем небольшой over-framework под себя.
А Convention насчет папок View — это как раз пример стандартного «opinion»а :) Это вполне можно поменять, реализовав свой ViewEngine (можно даже унаследовать тот же RazorViewEngine или WebFormsViewEngine и поменять способы инициализации convention-свойств). Впрочем, как по мне — вот это как раз неплохое соглашение. Чем оно не устраивает?
Меня вот, кстати, больше напрягает, что по-умолчанию используется ActionInvoker, не дающий возможности возвращать ViewModel из Action'ов контроллеров. Ну и, само собой, то, что многое завязано на HttpContext (включая HtmlHelper'ы), что усложняет тестирование.
А Convention насчет папок View — это как раз пример стандартного «opinion»а :) Это вполне можно поменять, реализовав свой ViewEngine (можно даже унаследовать тот же RazorViewEngine или WebFormsViewEngine и поменять способы инициализации convention-свойств). Впрочем, как по мне — вот это как раз неплохое соглашение. Чем оно не устраивает?
Меня вот, кстати, больше напрягает, что по-умолчанию используется ActionInvoker, не дающий возможности возвращать ViewModel из Action'ов контроллеров. Ну и, само собой, то, что многое завязано на HttpContext (включая HtmlHelper'ы), что усложняет тестирование.
По поводу тестирования всяких завязанных на HttpContext штук я химичу уже давно: sm-art.biz/Ivonna.aspx
А можно еще поподробнее про «согласно Догме 1, модель пассивна, а все действия совершает контроллер. А согласно Догме 2, модель не имеет права «знать» о доступе к данным.»?
Тут есть какое-то противоречие?
Тут есть какое-то противоречие?
Sign up to leave a comment.
Пять способов показать выпадающий список в Asp.Net MVC, с достоинствами и недостатками