>>View-шки все равно компилируются при использовании
Так фишка в том, что вы не получите ошибку на этапе компиляции, а лишь в рантайме при открытии страницы. А это ооочень плохо.
>>В общем, я бы не стал делать что-то, если бы оно мне лично не было бы удобно и с этой реализацией проблем не было
Интересно :) Все мы действуем лишь в рамках наших текущих знаний. И то, что кажется удобным, может оказаться унылым говном.
>> если задача того стоит — можно использовать и динамики
Если стоит — безусловно. Но в приведенном вами случае считаю, что оно того не стоит. Те же недостатки, что и у обычных строк, так еще и работает медленнее вдобавок (dynamic использует пусть и оптимизированный, но все же reflection).
Есть статья Phil Haack об этом. Там есть ссылка на презентацию, где на 25 слайде приводится сравнение.
Проблема строго-типизированного ActionLink'а заключается в том, что скомпилированный Expression Tree нельзя закешировать, если в Action передаются параметры. T4MVC лишен этого недостатка, потому что он эмулирует строгую типизацию (внутри все равно строки).
Занятно. Но вот что-то мне подсказывает, что разного рода библиотеки и тулзы (вроде T4MVC), которые рассчитаны на стандартную структуру папок, работать перестанут…
Я слышал примерно такую же «аргументацию», и она не укладывается у меня в голове. По-моему это детский лепет, а не аргументация.
Много кода? Так кода больше не становится. Сущностей (интерфейсов, классов) становится больше — да. Но это необходимое «зло».
Непонятно? Это вопрос профпригодности и компетентности
Путаница? Путаница — это когда все намешано в кучу. А когда система строится по принципам SOLID, у каждого класса и у каждого метода есть своя ответственность (причем одна).
Скорее нет, чем да. С переходом на SOLID я не отказался от статических классов, но стал их использовать гораздо реже: статическими я делаю только не классы, которые мне не нужно будет стабить и/или мокить; в обратном же случае я делаю класс нестатическим и прокидываю как зависимость.
А с базовыми принципами и паттернами так часто бывает: можно не знать об их существовании, но при этом прийти к ним самостоятельно. Но у самостоятельно изобретения паттернов и принципов есть ряд недостатков: 1. паттерны и принципы формируют язык, при помощи которого вы можете общаться с коллегами (с «самопальными» паттернами это не работает) 2. в книгах и сообществе с очень высокой вероятностью паттерны и принципы лучше проработы, выявлены их плюсы и минусы и т. д.
Поясню, откуда возник опрос. Пообщался с коллегами из непоследних компаний и обнаружил, что многие не следуют принципам SOLID. Это меня сильно удивило, потому что я придаю этим принципам очень серьезное значение. Стало интересно узнать статистику на более широкой выборке людей.
Особый интерес для меня представляет мнение людей, которые осознанно не используют SOLID. Но предлагаю оставить за пределами данного обсуждения ситуацию, когда SOLID (да и не только SOLID) не используется из-за убогого legacy-кода, рефакторить который нет ни ресурсов, ни желания: в таких ситуация зачастую выбирать не приходится.
В общем случае — да, операции, которые могут выиграть от наличия индексов лучше выносить в базу. Но для текущего примера это не так (см. выше), и для 1кк записей вторая реализация все равно быстрее.
Итак. 1 миллион заказов, где CustomerId заполнен случайным образом в диапазоне от 1 до 1000 (то есть на каждый CustomerId приходится порядка 10к заказов). Сделал 3 замера (для 3, 5 и 10 CustomerId):
Единица измерения — милисекунды. 3-я реализация — вторая с добавленным OrderBy CustomerId (чтобы проверить влияние сортировки).
Насчет влияния сортировки (2 vs. 3). Дефолтная реализация GroupBy из Linq To Objects не получается выигрыша в производительности, если список элементов отсортирован. Так что разница между 2 и 3 реализация — скорее всего, просто погрешность. Другое дело, что можно было бы реализовать своей метод OrderGroupBy… но это уже совсем другая история.
Если кто-то захочет воспользоваться, то новая версия доступна под ревизией 51feba67b023 здесь
Так фишка в том, что вы не получите ошибку на этапе компиляции, а лишь в рантайме при открытии страницы. А это ооочень плохо.
>>В общем, я бы не стал делать что-то, если бы оно мне лично не было бы удобно и с этой реализацией проблем не было
Интересно :) Все мы действуем лишь в рамках наших текущих знаний. И то, что кажется удобным, может оказаться унылым говном.
>> если задача того стоит — можно использовать и динамики
Если стоит — безусловно. Но в приведенном вами случае считаю, что оно того не стоит. Те же недостатки, что и у обычных строк, так еще и работает медленнее вдобавок (dynamic использует пусть и оптимизированный, но все же reflection).
Проблема строго-типизированного ActionLink'а заключается в том, что скомпилированный Expression Tree нельзя закешировать, если в Action передаются параметры. T4MVC лишен этого недостатка, потому что он эмулирует строгую типизацию (внутри все равно строки).
Лень проверять, совместим ли T4MVC с PortableAreas, поэтому спросил на StackOverflow (разработчик T4MVC David Ebbo фолловит тег t4mvc): stackoverflow.com/questions/6659788/is-t4mvc-compatible-with-portable-actions
Много кода? Так кода больше не становится. Сущностей (интерфейсов, классов) становится больше — да. Но это необходимое «зло».
Непонятно? Это вопрос профпригодности и компетентности
Путаница? Путаница — это когда все намешано в кучу. А когда система строится по принципам SOLID, у каждого класса и у каждого метода есть своя ответственность (причем одна).
Особый интерес для меня представляет мнение людей, которые осознанно не используют SOLID. Но предлагаю оставить за пределами данного обсуждения ситуацию, когда SOLID (да и не только SOLID) не используется из-за убогого legacy-кода, рефакторить который нет ни ресурсов, ни желания: в таких ситуация зачастую выбирать не приходится.
3 5 10
1. 7267 11532 19987
2. 5123 8685 17839
3. 5025 8950 17239
Единица измерения — милисекунды. 3-я реализация — вторая с добавленным OrderBy CustomerId (чтобы проверить влияние сортировки).
Насчет влияния сортировки (2 vs. 3). Дефолтная реализация GroupBy из Linq To Objects не получается выигрыша в производительности, если список элементов отсортирован. Так что разница между 2 и 3 реализация — скорее всего, просто погрешность. Другое дело, что можно было бы реализовать своей метод OrderGroupBy… но это уже совсем другая история.