hVostt

зашем? @Html.EditorFor(x => x.Prop)

в шаблоне для Prop лежит @Html.DropDownList("")

и волки целы и овцы сыты[/quot]
Какой бред. Зачем мне эта петрушка в залипушками в проекте? Это не проект, это какая-то свалка отходов. И всё ради чего, ради банальной отрисовки комбобокса? Завязывай уже с наркотой :)

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

hVosttМСУТипизация - это демагогия? Ну могу посоветовать только убиться после таких слов :)
если ты не понял, я против типизации ничего не имеют против. только за. SelectList офигенно типизирован для любой коллекции ключ-значение. кладётся он во вьюбэг не просто по какому-то выдуманному ключу, а по ключу поля, к которому привязывается. это здесь тоже можно обойтись без магических строк и получать из мета. ниче не сломается, и тестится великолепно.
Постой. Только что ты рвал горло и вопил о том, что




наше всё. Теперь ты говоришь, что у тебя всё типизированно и здорово. Какая типизация может быть в том, что я написал выше? Или ты пытаешься как-то выкрутиться и придумываешь всё новые и новые схемы самонаёба в виде @Html.EditorFor(x => x.Prop)?

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

В моём варианте никаких дополнительных танцев с бубнами не нужно, имеем честную модель, имеем прозрачный вью, имеем линейную логику инициализации модели. Всё настолько просто, насколько это можно себе представить. Зачем мне тут атрибуты, фильтры, шаблоны с Prop, волки и овцы?

handmadeFromRuтебе показалось
Ок, пусть будет так.

handmadeFromRuМСУК тому, что вью модель не нужно тестировать?

да. там нет логики и не должно быть, там готовые данные на отображение
В любой более или менее сложной системе во вью есть всегда логика. Начиная от валидаторов (WebForms), javascript и т.д., и кончая навороченным умным разором с его @if и @else для генерации html. Особенно разор очень удобен для логики генерации контролов на основе прав пользователя.

handmadeFromRuмое предложение было что списки для вью можно прокинуть через вьюбаг и не более, так что не надо. Потом я согласил что это составляющая вьюмодели. Но к примеру если каскадные списки получится вьюмодель без списков, только с ключами.
Какая разница, какие списки, каскадные или феерические, с лампочками и рюшечками или с коровьим выменем. UI может быть самым разнообразным, а его модель неизменна. В том весь и цимус, что если модель содержит все данные для работы, UI можно строить любой без вмешательства в серверный код. Кстати, в этом же плюс и чудесного MVVM. Модель есть, она всё содержит в себе. UI меняй хоть каждый день и ни о чем не думай. Это очень удобно.

handmadeFromRuпокажи мне как ты покроешь тестами вью с логикой.

hVosttкакой-то узкий и однобокий у тебя взгляд на вещи. это обсолютно стандартные решения, нативные -- всё как ты любишь
Так никто и не говорит про нестандартность. Нетипизированная DataTable тоже нативщина, но использовать её взамен человеческих ORM есть зло (отдельные случаи не в счет, когда схема данных динамична и типизация идет лесом). Даже имея в руках стандартную лопату можно сломать себе ногу. У тебя как-раз именно такой случай.

hVosttопять 25. при чём же тут твой XAML? MVVM это паттерн. что там и как делается в XAML по барабану вообще. паттерн MVVM более общий, и применяется в том числе при разработке клиентского JavaScript приложения, где XAML-ом и его отходами даже не пахнет.
Что значит причем? Я же тебе объяснил, я хочу использовать модель представления и в XAML морде в том числе. С минимальными переделками, если они будут. Я хочу прозрачную модель, полно описывающую представление. JS по возможностям XAML даже рядом не валялся, как-то глупо даже сравнивать это. То, что в JS можно ваять убогие MVVM залипушки на кнокауте - жалкое подобие того, что можно вытворять на XAML.

hVosttестественно всё типизировано
1. Где тут типизация? @Html.DropDownList("CategoryId")
2. У тебя модель неполная, данные в UI наполняются через какой-то левый свищ, а не через модель.
3. System.Web.Mvc.SelectList это не типизация и в модели этой фигне делать нечего.
Так где ж у тебя "всё типизировано"?

hVosttшаблоны для EditorFor -- стандартное решение, предложенное вендором и повсеместно используемое. и ещё пока ни один кролик не пострадал. я не понимаю с чем ты споришь. хочешь сделать заявление по поводу того, что ASP.NET MVC спроектировала команда мудаков? и нада же, приделали мерзкий ViewBag, дибильные Editor/Display шаблоны, вот же мерзкие хоббитцы
Я тебе уже писал, зачем мне тут шаблоны для EditorFor? Только упоротый кролик будет для комбобоксов создавать шаблоны, создавать отдельные атрибуты, прикручивать их к методам контроллеров. И всё ради того, чтобы наполнить комбобоксы? Это просто верх тупости

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

hVosttтебе хз. но вообще это стандартные инструменты, заложенные изначально и развивающиеся до сих пор. если бы эти штуки были бы неудачным решением, отсохло бы ещё на 2-ой версии. просто ты не умеешь ASP.NET MVC готовить.
Я повторяю, никто не говорит тебе, что это нестандартные инструменты. Тебе говорят о том, что для данной задачи эти инструменты не подходят. Абсолютно. Толковый кодер тем и хорош, что применяет правильные инструменты в той задаче, где это нужно. А не пихает их куда ни попадя, а потом заявляет, мол он же применил стандартные инструменты. На счет неумения мною готовить MVC я тихо поржал над тобой в сторонке. Ага.

hVosttты применяешь подход аналогичный в XAML, где может ты и плаваешь как рыба в воде. но ASP.NET MVC здесь вполне уместно применять то, что было предложено разработчиками. по большей части. с чем ты споришь, непонятно
Я не применяю подход, аналогичный в XAML. Срать вообще на XAML и всё стальное, речь не о том - я применяю подход, который граничит с здравостью ума и гибкостью архитектуры. В твоём случае - ни здравости ума, ни гибкости в архитектуре. Как всегда, двойка тебе.

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

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

hVostteJack"надоело" -- это то, что программиста делает программистом. а за "уволен", пожизненный ярлык "самодур" без навыков самостоятельного мышления. слишком много умных книжек видемо начитались. эх....
Надоело - это то, что программиста делает гавном. Есть требования свыше от руководителя, есть архитектура, есть конкретная задача, есть сроки - сиди и пили. Надоело - иди коров паси. А "самодур" или "дуросам" - это всё детский сад, не иначе. Когда сам станешь руководителем, будешь принимать на работу людей и увольнять их, ставить задачи, контролировать выполнение, наказывать за фэкапы и прочие косяки, заслонять своих людей от нападков злого бизнеса, премировать и депримировать отличившихся и так далее - вот тогда и поговорим. А пока забейся в свой угол и пиши такой код, который говорят тебе дяди. Если не будешь этого делать - уволен нах. Самодеятельность и прочая феерическая манера поспорить с руководством о правильности кода - даже в детском садике пресекается.

handmadeFromRuХорош цепляться к словам) я ж не написал просто надоело и не хочу. а добавил причину, потому что мне так показалось, возникли сомнения . Если кто то считает что это не причина, это его воля так судить и думать я что плохой программист т.к. можно в след раз и не слушать меня.
handmadeFromRu...я раньше также в модель прокидывал, но надоело. Ощущение искусственности
Я не понимаю тебя, о какой искуственности идет речь?

На пальцах. Вот моя модель представления, по сути какая-то транзакция по клиенту c доступными и выбранным состояниями.




Данная модель представления как нельзя лучше и полно описывает представление. Представление может быть любым. И WebForms, и MVC, и XAML, и WinForms, и так далее (либо с минимальными (!) переделками).

Вот конкретно для MVC моё UI, а конкретно - комбобокс для состояний.




Как видишь, никаких левых вью багов, шаблонов, фильтров и прочей ереси. Что может быть проще?