Мне кажется, наоборот — хорошо. «Когда в руке молоток — всё кажется гвоздём» — часто вижу когда в подобные ФорИчи втыкают несколько-строчные лямбды — Ну почему не воспользоваться нормальным человеческим foreach?
В C#.NET тоже есть оптимизация компилятором, например строка кода вида
string a = b + c + d;
заменится на string a = string.Concat(b,c,d) который не будет создавать лишних объектов.
Да, но если речь идёт о сферических тестах, то вот такой paste.org.ru/?tllr43 даёт интересные результаты: быстрее всего string.Join, потом String.Concat, a потом уже StringBuilder.
String.Join использует хитрый UnSafeCharBuffer.
Имхо, это даже быстрее чем если сделать:
foreach (var item in someArray) stringBuilder.Append(item.ToString());
т.к. string.Concat сразу создаст строку нужной длины через FastAllocateString и FillStringChecked-ами её заполнит.
А ещё нет полезного совета:
string left = «2+2=»;
int right=4;
string exp = left + right;
в последней строке лучше сделать
string exp = left + right.ToString();
чтобы избежать лишней потери производительности на боксинг переменной right
Дочитав до этой строки сразу бросил читать.
ЗЫ: проблему можно решить по хард-кору через указатели (unsafe code) отключив интернирование чтобы не получить неожиданные результаты :-) (кто воспримет это серьёзно — тот зануда).
Я не называл его анти-паттерном, прочтите ещё раз мой комментарий.
PS: цитата из Фаулера:
With dependency injector you can just look at the injection mechanism, such as the constructor, and see the dependencies. With the service locator you have to search the source code for calls to the locator.
Брр… просматривать весь код на предмет — какие же всё-таки зависимости используются, когда можно просто раз глянуть на конструктор — по-моему, выводы очевидны.
Если у вас экземпляр создается внутри стороннего метода, требующего paramtereless constructo, к примеру ServiceHost(typeof(MyService)) — то DI вам тут НИКАК не поможет. Property Injection — это лишь альтернатива Constructor Injection с той лишь разницей, что через PI можно использовать цикличные зависимости.
Спасибо, я лично не переживаю, -24 говорит о том, что на хабре как миниум n-24 адекватных людей :-). С людьми, у которых в голове эта самая мантра «Си быстрее» без конкретного контекста, диалога обычно не получается.
По поводу ServiceLocator-a согласен с автором, что в домене его не должно быть и не понимаю в чем тут может быть дисскусия. В остальных слоях — пожалуйста (но там где нельзя использовать DI).
Чаще всего в такого рода проектах узким местом является архитектура, непродуманность которой пораждает неоптимизированные запросы\излишние их количеств — пиши ты хоть на ассемблере. Разница будет только в скорости написания кода и рефакторинга этой самой архитектуры.
Select из коробки так умеет (одна из его перегрузок)
Ковчег построил любитель, профессионалы построили «Титаник».
А если в процессе работы алгоритма станция из-за него грохнется? :-)
string a = b + c + d;
заменится на string a = string.Concat(b,c,d) который не будет создавать лишних объектов.
String.Join использует хитрый UnSafeCharBuffer.
foreach (var item in someArray) stringBuilder.Append(item.ToString());
т.к. string.Concat сразу создаст строку нужной длины через FastAllocateString и FillStringChecked-ами её заполнит.
string name = string.Concat(firstName, " ", lastName);он не имеет никаких преимуществ в затратах.
string left = «2+2=»;
int right=4;
string exp = left + right;
в последней строке лучше сделать
string exp = left + right.ToString();
чтобы избежать лишней потери производительности на боксинг переменной right
ЗЫ: проблему можно решить по хард-кору через указатели (unsafe code) отключив интернирование чтобы не получить неожиданные результаты :-) (кто воспримет это серьёзно — тот зануда).
PS: цитата из Фаулера:
With dependency injector you can just look at the injection mechanism, such as the constructor, and see the dependencies. With the service locator you have to search the source code for calls to the locator.
Брр… просматривать весь код на предмет — какие же всё-таки зависимости используются, когда можно просто раз глянуть на конструктор — по-моему, выводы очевидны.
PS: необязательно выносить все зависимости в конструктор — можно через свойства (Property Injection).