А автор T4MVC признает проблемы :)
Любопытно, как у вас получилось всё хорошо. У меня тоже были проблемы с тем, что структура проекта, требуемая Portable Areas не совпадает с требованиями T4MVC. В итоге небольшой патчик на T4MVC решил проблему, но у вас, видимо, было как-то по-другому. Поделитесь?
Это издержки того, что библиотека получается «цельной».
То есть чтобы её использовать достаточно просто подключить в проект один файл, и не требуется таскать за собой вьюшки.
В некоторых случаях это может быть неудобно, да. Но плюсы «цельности» для меня лично перевешивают.
дженериковские экшн-линки лично мне нравятся больше, чем T4MVC (и использую я их), поэтому насчет работоспособности T4MVC ничего сказать к сожалению не могу.
Но T4MVC — это тот же MvcContrib, так что не исключено, что какой-то workaround таки есть.
Я как-то видимо неправильно выразился в топике, что ли.
Я как раз про выделение функционала в отдельные модули = отдельные .dll-ки.
Отличие от плагинов минимальное, насколько я понимаю. Найден баг — исправляем в одном месте — в .dll-ке.
за референс на Orchard CMS спасибо, посмотрю.
Это нужно и для простых приложений, если у вас таких «простых» больше, чем одно и между ними есть общий функционал :)
Подключать «копированием в папку» — это хорошо, если у вас CMS, в которой есть стандарт для плагинов и есть GUI для их включения/выключения.
А если у вас не «плагин» как таковой, а часть сайта, с которой вы достаточно плотно работаете из основного приложения (запрашиваете данные/используете сервисы), то в подключении референса нет ничего неудобного. А совсем даже наоборот.
как думаете, в среднем, из 10 спрашивающих «стоит ли написать на тему» или в комментах оставляющих «я знаю, как лучше, подробнее скоро напишу статью» реально пишут статью? :)
вот потому и реакция на подобные посты. Если их автор, конечно, не признанная знаменитость.
а оба провайдера вам — «домашнему пользователю» — маршрутизируют один и тот же айпишник?
или у проекта два адреса, которые могут работать попеременке? :)
Второе — моё. Логирует через добавление атрибута [Log] в AssemblyInfo требуемого проекта. Ну и требуется руками создать инстанс логгера в статическом поле статического класса.
Изменения, имхо, минимальны :)
* Объяснить зачем это нужно разработчикам и руководству
это вот всё-таки важный, но нераскрытый момент :) Особенно в контексте «зачем нужно руководству».
Краткий ответ: потому что не появляются задержки от работы с системой контроля версий.
Это не слишком весомый аргумент. Задержки на связь с локальным хранилищем при 100% работе в рамках офиса — фактически никакие.
А переход на новую систему контроля версий — это сама по себе задержка/время/деньги.
Boy Scout rule.
Всегда оставляйте за собой код чище, чем он был. Со временем наиболее меняющиеся части станут адекватными. Новые части будут нормальными сразу. Остальное закостенеет в рабочем состоянии :)
Это долго и надо много упорно работать. Или вы хотели попроще и побыстрее? :)
э… а интуиции кого из новичков лучше довериться, если их несколько, и их интуиции говорят прямо противоположные вещи?
А занудой быть так не хочется! :)
Демократия, имхо, не рулит совершенно. На всех уровнях управления, всем менеджерам проще при четкой иерархии.
Другое дело, что на исполнительском уровне демократия создаёт общую позитивную атмосферу и повышает производительность, поэтому именно там всякими аджайлами её и эмулируют.
А выше исполнительского уровня — принятия решений. И если при принятии решений мы строим демократию и будем голосовать — получится первый пункт.
Аргументация может быть и проще.
Привыкли, «и так всё работает» с одной стороны, а с другой стороны то, что в обучение новой методике надо вкладывать деньги/время, и первое время эта самая новая методика только замедлит процесс выдачи результата (собственно, здесь SOLID от любой другой новинки не отличается — с любой технологией сначала идет замедление).
А с другой стороны — со стороны «профпригодности» — допустим, работает в фирме 20 человек из которых 5 очевидно эту новую методологию не потянут. Но в существующих реалиях эти пятеро работают, и нормально. Что делать? А искать новых людей сложно!
Есть еще и третья сторона — руководитель может в новой технологии не разбираться. А он привык, что все технические детали раньше тоже глубоко понимал. Как менеджеру ему это, может, и не надо, но он понимал. А сейчас пришел человек революцию делать. А вдруг он потом уйдет. И кроме него никто всех деталей просто и не знает. Риски? Риски.
А может быть и еще проще — коллектив «стабильный» и никто про это даже и не знает. И всем хорошо :)
да, всё до смешного просто :)
Смутило то, что папки App_Code по умолчанию в проекте нет. Добавил, положил туда хелпер — всё заработало.
Правда, появился вопрос, что делать, если я хочу расшарить хелперы только между двумя-тремя вьюшками — то есть не хочу их добавлять в глобально-доступный Helpers из App_Code.
Что-нибудь типа @using LocalHelperNamespace, но какой у этого хелпера будет неймспейс?
назвать его, к примеру, Helpers.cshtml, положить его в AppCode
Извините за глупый вопрос, но можно чуть поподробнее про «положить в AppCode»? Куда надо положить/что сделать, чтобы использовать хелперы из Helpers.cshtml в другой вьюшке?
Любопытно, как у вас получилось всё хорошо. У меня тоже были проблемы с тем, что структура проекта, требуемая Portable Areas не совпадает с требованиями T4MVC. В итоге небольшой патчик на T4MVC решил проблему, но у вас, видимо, было как-то по-другому. Поделитесь?
И в случае переименования Экшена или параметра в экшене — оно нормально отработает в вашей реализации?
Посмотрел подробнее на T4MVC — да, он любопытен, надо-таки попробовать.
То есть чтобы её использовать достаточно просто подключить в проект один файл, и не требуется таскать за собой вьюшки.
В некоторых случаях это может быть неудобно, да. Но плюсы «цельности» для меня лично перевешивают.
Но T4MVC — это тот же MvcContrib, так что не исключено, что какой-то workaround таки есть.
Я как раз про выделение функционала в отдельные модули = отдельные .dll-ки.
Отличие от плагинов минимальное, насколько я понимаю. Найден баг — исправляем в одном месте — в .dll-ке.
Это нужно и для простых приложений, если у вас таких «простых» больше, чем одно и между ними есть общий функционал :)
Подключать «копированием в папку» — это хорошо, если у вас CMS, в которой есть стандарт для плагинов и есть GUI для их включения/выключения.
А если у вас не «плагин» как таковой, а часть сайта, с которой вы достаточно плотно работаете из основного приложения (запрашиваете данные/используете сервисы), то в подключении референса нет ничего неудобного. А совсем даже наоборот.
вот потому и реакция на подобные посты. Если их автор, конечно, не признанная знаменитость.
или у проекта два адреса, которые могут работать попеременке? :)
Оупенсорс-проект на базе Mono.Cecil
Обе меняют IL.
Второе — моё. Логирует через добавление атрибута [Log] в AssemblyInfo требуемого проекта. Ну и требуется руками создать инстанс логгера в статическом поле статического класса.
Изменения, имхо, минимальны :)
это вот всё-таки важный, но нераскрытый момент :) Особенно в контексте «зачем нужно руководству».
Это не слишком весомый аргумент. Задержки на связь с локальным хранилищем при 100% работе в рамках офиса — фактически никакие.
А переход на новую систему контроля версий — это сама по себе задержка/время/деньги.
Всегда оставляйте за собой код чище, чем он был. Со временем наиболее меняющиеся части станут адекватными. Новые части будут нормальными сразу. Остальное закостенеет в рабочем состоянии :)
Это долго и надо много упорно работать. Или вы хотели попроще и побыстрее? :)
А занудой быть так не хочется! :)
Демократия, имхо, не рулит совершенно. На всех уровнях управления, всем менеджерам проще при четкой иерархии.
Другое дело, что на исполнительском уровне демократия создаёт общую позитивную атмосферу и повышает производительность, поэтому именно там всякими аджайлами её и эмулируют.
А выше исполнительского уровня — принятия решений. И если при принятии решений мы строим демократию и будем голосовать — получится первый пункт.
Установка тоже из исходников, запуск через fastcgi, ставилось на убунту.
Привыкли, «и так всё работает» с одной стороны, а с другой стороны то, что в обучение новой методике надо вкладывать деньги/время, и первое время эта самая новая методика только замедлит процесс выдачи результата (собственно, здесь SOLID от любой другой новинки не отличается — с любой технологией сначала идет замедление).
А с другой стороны — со стороны «профпригодности» — допустим, работает в фирме 20 человек из которых 5 очевидно эту новую методологию не потянут. Но в существующих реалиях эти пятеро работают, и нормально. Что делать? А искать новых людей сложно!
Есть еще и третья сторона — руководитель может в новой технологии не разбираться. А он привык, что все технические детали раньше тоже глубоко понимал. Как менеджеру ему это, может, и не надо, но он понимал. А сейчас пришел человек революцию делать. А вдруг он потом уйдет. И кроме него никто всех деталей просто и не знает. Риски? Риски.
А может быть и еще проще — коллектив «стабильный» и никто про это даже и не знает. И всем хорошо :)
P.S. Сам — «за», не поймите неправильно :)
Смутило то, что папки App_Code по умолчанию в проекте нет. Добавил, положил туда хелпер — всё заработало.
Правда, появился вопрос, что делать, если я хочу расшарить хелперы только между двумя-тремя вьюшками — то есть не хочу их добавлять в глобально-доступный Helpers из App_Code.
Что-нибудь типа @using LocalHelperNamespace, но какой у этого хелпера будет неймспейс?
Извините за глупый вопрос, но можно чуть поподробнее про «положить в AppCode»? Куда надо положить/что сделать, чтобы использовать хелперы из Helpers.cshtml в другой вьюшке?
но вопрос-то мне, надо ответить :)