Вьюстейт с MVC использовать нельзя, концепция этих подходов к разработке разная.
MVC принимает http протокол как неизбежность, и не пытается оградить разработчиков от него, городя абстракции, жизненный цикл страницы, вьюстейты и апдейтпанели. Плюс используется MVC паттерн, что делает проекты дружелюбными к юнит тестам, например.
Web Forms же пытается косить под WinForms, но жизнь есть жизнь, и у такой дружелюбности к тем, кто переходит с вин формс, есть своя цена вроде таких штук. Ещё одна цена — невозможность сайта работать с отключённым джаваскриптом.
Нельзя отбирать у пользователя то, что у него уже есть. Это закон. Крутитесь как хотите, придумывайте новые фичи, но не отбирайте то, что есть. У меня в браузер поиск по странице встроен, а его у меня отобрали.
По существу: убогая инфографика, отжирающая 50% процессора, и среднепотолочные числа.
Моё мнение по первому вопросу — это тот случай, когда кодогенерация удобна и уместна. Впрочем, это вопрос не столько программирования как такового, а, скорее, предпочтения определённого набора инструментов. Я стараюсь избегать привязки к каким-либо ключам, а всё строго типизировать, в таком случае решарпер и студия значительно помогают.
Потом не стесняюсь писать прямо во вьюшке что-то вроде
@MyApplication.Resources.Localization.Common.LogIn
Что касается второго вопроса — то я свято верю, что в данном случае именно вьюшка задаёт условия и соглашения, при которых её можно использовать. И если контроллер не в эти соглашения выполнить — нужно изменять контроллер, а не вьюшку.
Эм, нет. UserSpecificField и AdminSpecifiField — свойства разных моделей.
public class UserRegistrationModel: IAccountRegisterForm
{
…
String UserSpecificField{get; set;}
}
public class AdminRegistrationModel: IAccountRegisterForm
{
…
String AdminSpecifiField{get; set;}
}
За регистрацию пользователя и администратора отвечают различные страницы с различными моделями. Но общие свойства этих моделей описаны интерфейсом, и для отображения этих общих свойств используется общая вьюшка.
Тогда случай, описанный в статье, становится просто частным случаем. А одну и ту же вьюшку можно использовать для отображения общих данных различных моделей — если они наследуют один и тот же интерфейс.
В данном случае примером может быть, регистрация пользователя и администратора, если этот процесс несколько отличается валидацией и набором полей.
Не совсем понятно из статьи, содержит ли результат выдачи Гугла слова-приманки. Если он выдаёт страницы без таких слов, то претензии действительно обоснованы. Ну а если нет — то воздух общий, чего уж тут.
Иненно так я поисковые подсказки реализовывал на одном из проектов. Там, правда, добавил такую характеристику узлам, как частота, чтобы показывать наиболее популярные запросы первыми.
habrahabr.ru/blogs/image_processing/120562/
habrahabr.ru/blogs/subconsciousness/37615/
MVC принимает http протокол как неизбежность, и не пытается оградить разработчиков от него, городя абстракции, жизненный цикл страницы, вьюстейты и апдейтпанели. Плюс используется MVC паттерн, что делает проекты дружелюбными к юнит тестам, например.
Web Forms же пытается косить под WinForms, но жизнь есть жизнь, и у такой дружелюбности к тем, кто переходит с вин формс, есть своя цена вроде таких штук. Ещё одна цена — невозможность сайта работать с отключённым джаваскриптом.
По существу: убогая инфографика, отжирающая 50% процессора, и среднепотолочные числа.
Потом не стесняюсь писать прямо во вьюшке что-то вроде
@MyApplication.Resources.Localization.Common.LogIn
Что касается второго вопроса — то я свято верю, что в данном случае именно вьюшка задаёт условия и соглашения, при которых её можно использовать. И если контроллер не в эти соглашения выполнить — нужно изменять контроллер, а не вьюшку.
public class UserRegistrationModel: IAccountRegisterForm
{
…
String UserSpecificField{get; set;}
}
public class AdminRegistrationModel: IAccountRegisterForm
{
…
String AdminSpecifiField{get; set;}
}
За регистрацию пользователя и администратора отвечают различные страницы с различными моделями. Но общие свойства этих моделей описаны интерфейсом, и для отображения этих общих свойств используется общая вьюшка.
На другой
@model UserRegistrationModel
…
@Html.Partial(«CommonRegisterForm», Model)
@Html.TextBoxFor(m => m.UserSpecificField)
…
@model AdminRegistrationModel
…
@Html.Partial(«CommonRegisterForm», Model)
@Html.TextBoxFor(m => m.AdminSpecifiField)
На другой
Интерфейс
public interface IAccountRegisterForm
{
string Name { get; set; }
string State { get; set; }
void Validate();
}
Модель
public class AccountRegisterForm: IAccountRegisterForm
{
[Required]
public string Name { get; set; }
[Required]
public string State { get; set; }
public void Validate(){}
}
Вьюшка
@model IAccountRegisterForm
…
@Html.TextBoxFor(m => m.Name)
…
Тогда случай, описанный в статье, становится просто частным случаем. А одну и ту же вьюшку можно использовать для отображения общих данных различных моделей — если они наследуют один и тот же интерфейс.
В данном случае примером может быть, регистрация пользователя и администратора, если этот процесс несколько отличается валидацией и набором полей.
— Киса, я спрошу вас как художник художника. Вы рисовать умеете?
… выделяя при этом углекислый газ! Предлагаю начать с себя и прекратить дышать.
bash.org.ru/abyssbest?text=89.3