Почему пишут до сих пор




?

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

А иначе как рефакторить? Поменял название вьюхи - идти искать полнотекстовым поиском по проекту, где это название в строковом виде используется? Совсем, чтоли?

Вот вы как это дело обходите? Или не обходите, а всё в строках пишете и рефакторинг для вас ад?

skyANA"Как можно быстро и удобно сделать, чтобы выбор представлений... был типизированным "?

Прикинь, надо создать тип:


и использовать его, а не "название в строковом виде":


Круто. А что вы используете вместо Разора?

И можешь дать ссылку, где бы подобный же подход применялся? Ты сам до него додумался, или в МСДНе где прочитал? Ну просто интересно, почему я больше нигде подобного не встречал.

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

А если названия сущностей прямо в сами сущности запихать? Ну, типа соглашение по проекту такое - название сущности в статическом константном свойстве, которое задаётся при старте приложения? И рефлексией при старте приложения их вытащить, а не опять же захардкоденными строками?

Под сущностями я имею ввиду названия контроллеров и представлений - то, что в "классических примерах" по ASP.NET MVC любят так срамотно захардкоденными строками напоказ выставлять.

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

И зачем тогда городить огород со специальным классом со строковыми списками сущностей?

Скайана, почему ты не используешь выражения для вытаскивания названий сущностей, а используешь какие-то строковые их списки?

AxeleronИспользование Reflection - дорогое удовольствие. Это раз. А два - что оно даст в Run-time, если название view определяется в Compile-time?
Не рефлексия, а выражения. И важно ли это, если только один-три раза на запрос? Там конвеер маршрутизации, атрибуты и прочие бандлинги и обработка ошибок и логирование сжирает в разы, если не на порядки, больше, чем пара обращений по рефлексии.

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

ИзопропилAlexey2112А вообще, ведь использование пользователем сайта не подразумевает десятки и сотни действий в секунду.
с чего это?
Ну сколько ты накликаешь по ссылкам за секунду?

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

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

Алексей КAlexey2112Хотя, довольно дурацкий подход - надо держать класс со списком всех сущностей проекта, не забывать обновлять этот класс, как только сущности обновил.Можно использовать кодогенерацию. Возьми T4 Text Template, пробегись по проекту, найди все контроллеры, вьюхи или что там надо, сгенерируй класс со строковыми константами. В чём проблема?
Да много способов решения есть. Я тут народ разогреваю, чтобы идеи генерировал. Вон, Скиана уже завёлся.

Алексей КskyANAпропущено...
В этом: 17829736 :)А вообще, в погоне за глобальной статической типизацией можно дойти до маразма. Поэтому наверняка изобретены какие-нибудь автотесты, проверяющие все ссылки в проекте...
У кого изобретены?

skyANAАлексей Кпропущено...
А вообще, в погоне за глобальной статической типизацией можно дойти до маразма. Поэтому наверняка изобретены какие-нибудь автотесты, проверяющие все ссылки в проекте...Для Razor? Наверняка у кого-нибудь ViewEngine достает представления по имени из базы :)
Ты на себя намекаешь?

И вообще, чё вы все говорите в стиле "у моей подруги с её парнем" ? Это что-то постыдное? Боитесь признаться? Ведь на МСДНах и во всяких блогах об этом много не пишут, если пишут вообще.

skyANAАлексей Кпропущено...
А вообще, в погоне за глобальной статической типизацией можно дойти до маразма. Поэтому наверняка изобретены какие-нибудь автотесты, проверяющие все ссылки в проекте...Для Razor? Наверняка у кого-нибудь ViewEngine достает представления по имени из базы :)
Ты писал, что не используешь Разор. А что используешь?

Алексей КРешарпер не нужен... :-)
Согласен. У меня его нет. А на хабрах всяких постоянно пишут "не представляю, как бы я теперь жил без Решарпера". Школота несчастная...

skyANAАлексей Кпропущено...
Ну ведь можно регуляркой распарсить все вьюхи и проверить параметры всех, например, @Url.Action("A", "B") .И при чём тут actionName и controllerName , когда речь о partialViewName и viewName ?
Обо всём идёт речь. Имена всех контроллеров и всех вьюх. Вообще всё, что требуется в строковом виде задавать, должно иметь возможность задаваться в виде выражения.

А "регулярками проходиться" - детский лепет. Задолбаешься писать эти регулярки для всех сочетаний @Url, @Ajax.BeginForm и прочих. Тем более, что с каждым новым выходом asp.net mvc там может что-нибудь поменяться. Короче, возможность юзать выражения в таких вот Ajax.BeginForm должна быть заложена изначально. И вообще, не понимаю, почему в дотнет до сих пор не добавили перегрузки с выражениями для всех методов, принимающих строковые имена сущностей языка. Изо всех подобных изменений припомню только CallerMemberName.

Фримен ЭспозитоНе переживайте , автор! Вангую , что к версии MVC 7 сделают полностью типизированные вьюхи.
Ты МСУ? Когда там у джавы перевернётся грузовик с асинками и выражениями!

Arm79Коллеги, может не в тему, но ReSharper умеет сам переименовывать такие названия
В смысле? Создатели Решарпера отслеживают весь состав всех перегрузок всяких @Url, @Html и прочих и проверяют, не изменилось ли название класса, метода или свойства, на которые они ссылаются? Представляю, сколько этот Решарпер оперативы зажирает. Ведь ему надо создать полную модель всех языковых сущностей приложения и следить за ней. Так же, как это делает Студия, но только теперь это продублирует Решарпер. Не зря эти из джетбрейнсов свою ИДЕ замутили (которая Идея) - замахиваются на замену своим плагином Студии. Это как Гугл замахивается на замену операционной системы своим браузером.

AxeleronAlexey2112Тем более, что с каждым новым выходом asp.net mvc там может что-нибудь поменяться. Короче, возможность юзать выражения в таких вот Ajax.BeginForm должна быть заложена изначально. И вообще, не понимаю, почему в дотнет до сих пор не добавили перегрузки с выражениями для всех методов, принимающих строковые имена сущностей языка. Изо всех подобных изменений припомню только CallerMemberName.
Потому что Java рулит
Она рулит тем, что у неё стабильность. Стабильность могилы. Нет ничего нового - нет и проблем.

AxeleronAlexey2112Тем более, что с каждым новым выходом asp.net mvc там может что-нибудь поменяться. Короче, возможность юзать выражения в таких вот Ajax.BeginForm должна быть заложена изначально. И вообще, не понимаю, почему в дотнет до сих пор не добавили перегрузки с выражениями для всех методов, принимающих строковые имена сущностей языка. Изо всех подобных изменений припомню только CallerMemberName.
Потому что Java рулит
А в Джаве можно сослаться на любую сущность и её свойство без захардкоденных строк?

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

AxeleronAlexey2112Она рулит тем, что у неё стабильность. Стабильность могилы. Нет ничего нового - нет и проблем.
Scala чем не нравится?
Я в хрен не знаю, что это такое и знать не хочу. Что за мода вообще пошла - хвалиться тем, что знаешь 20 разных способов сделать примерно одно и то же? Лучше сделай 20 разных вещей с помощью одного и того же инструмента за то же время - вот чего хочется.

AxeleronAlexey2112Лучше сделай 20 разных вещей с помощью одного и того же инструмента за то же время - вот чего хочется.
Тогда, Вам батенька, стоит обратить внимание на C++. Мощный инструмент (вкупе с набором библиотек), предназначенный как раз для данной задачи. Крайне рекомендую.
Он был таким до поялвения сишарпа и дотнета версии так 3-3.5. Теперь у С++ нет шансов и только ленивые старпёры, не желающие учиться новому и высасывающие из пальца +30% производительности (кому она впёрлась вообще?, да ещё ценой таких усилий) ещё за него держатся. Если бы не гамесы, то популярность с++ была бы в районе нуля и треба в основном для поддержки легаси.

AxeleronАлексей ККак-то обсуждалось, что будут проблемы с интеграцией разных частей программы, написанных на Scala и Java.

Например, прикладной код на Scala, а системные библиотеки на Java (Spring, Hibernate и т. п.) - получится ли?
Каюсь, это был некоторый вброс с моей стороны, так как мне показалось, что в теме МСУ детектед.
Я и есть МСУ. Только ещё маленький. Не вырос пока. Будущий МСУ.

Дино АдамКстати, никто не мешает создать параллельный WebAPI сервис - сервис генерирования имен вьюх например.
Овер джейсончик тащемта разумеется.
На первіе десять вьюх - бесплатная подписка, далее монетизировать.
Да херня все эти сервисы, МСУ.


Ладно.

Для получения имени контроллера подойдёт typeof(MyController).Name.

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

Для получения имени вьюхи предлагают какие-то костылики http://stackoverflow.com/questions/1268763/retrieve-the-current-view-name-in-asp-net-mvc
и то только для текущей вьюхи. Кстати, надо ведь ещё иногда не просто имя вьюхи, а полный путь к ней. Вот там такое и предлагается (имя текущей вьюхи-то как раз легко получить).

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

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

Ну и минус всех способов, что я выше описал - нет единообразия. То лямбды, то GetType, то typeof, то костыль какой-то.

Вот, я не одинок.
http://stackoverflow.com/questions/14178639/is-hardcoding-controller-view-and-action-names-in-mvc-good-practice

Кто-нибудь пробовал https://github.com/T4MVC/T4MVC ?



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





Эти вьюхи что, только в рантайме существуют? Типа, классы WebViewPage генерируются на лету при каждом обращении ко вьюхе (т. е. при каждом запросе) и потом сразу уничтожаются? .. Хмм А ведь догадка-то верная, похоже. Ведь когда в проекте изменил вьюху, то достаточно только сохранить её без перекомпиляции проекта - и изменения сразу вступят в силу. Зачем они это сделали? Это как с WPF, где замл не компилируется. Это же тормоза лишние? А плюсы этого какие?

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