Comments 31
Неплохая идея. Пошел писать аналог для java.
Чувствую себя вымирающим мамонтом. Я и 2.0 то не до конца еще заботал, а тут уже такое.
Рискуете потерять конкурентоспособность. Рекомендую ежедневно заглядывать на dotnetkicks.com.
Спасибо, я лучше буду дальше в глухой бакэнд уходить:) MS SQL в этом плане не так сильно летит вперед.
Это только кажется, пока не придется поработать с PowerShell, CLR процедурами и т.п. Синтаксисом второго сишарпа можно и в четвертом писать, а вот править то, что написали другие — не всегда.
извините, я не совсем понял, что вы хотите сказать.
Например целесообразно использовать в MS SQL хранимые процедуры, написанные на .NET'е.
Для некоторых задач будет работать и быстрее и проще.
Для некоторых задач будет работать и быстрее и проще.
а CLR, разумеется, нужно писать на 4.0, с использованием Lazy? :)
Не обязательно, но с этой точки зрения MS SQL летит вперёд настолько же быстро, как и сам .NET. Например технология LINQ to XML очень облегчает работу с XML из SQL Server'а, а в .NET 2.0 её нету.
Это как и везде — чем больше инструментарий, тем проще решать задачи.
Это как и везде — чем больше инструментарий, тем проще решать задачи.
Некогда точить пилу, надо пилить? :)
Нет, почему, пилу точу. Дело не в пиле, а в том, чтобы дать технологии время улежаться в голове, устаканиться. Летим ведь, непонятно куда.
в последнее время столько разных технологий у мелкософта появились даже для решений одних задач. что за всем физически не успеваешь.
Да уж… Мало применить технологию, нужно применить ее грамотно. Что бы применить грамотно нужно время для того, что бы попробовать, потестировать и найти оптимальный подход для использования (желательно на каком-нибудь некритичном проекте) плюс ко всему определить стратегию использования совместно с другими используемыми технологиями (или замены чего-либо).
А последнее время идет плотный поток технологий и их реализаций, на все физически не хватает рук и времени, да и постоянные смены технологий в проекте — зло.
Меня забавляют коллеги, которые прилетают и рассказывают с упоением о какой-то новой штучке, которые они непременно будут использовать вот прям сейчас и все, что они раньше использовали — устаревшее никому ненужное УГ (особенно смешно выглядел крайне увлеченный чувак, который рассказывал ген.директору о супер продвинутой технологии ZOPE… попробуйте послушать со стороны — это что-то).
А последнее время идет плотный поток технологий и их реализаций, на все физически не хватает рук и времени, да и постоянные смены технологий в проекте — зло.
Меня забавляют коллеги, которые прилетают и рассказывают с упоением о какой-то новой штучке, которые они непременно будут использовать вот прям сейчас и все, что они раньше использовали — устаревшее никому ненужное УГ (особенно смешно выглядел крайне увлеченный чувак, который рассказывал ген.директору о супер продвинутой технологии ZOPE… попробуйте послушать со стороны — это что-то).
Тем не менее, имхо, новым возможностям стоит радоваться, а не «сидеть в пещере с гоблинами» (с).
Я помню как я сам был недоволен странным синтаксисом LINQ и тем что они вообще городят непонятно что. Оказалось, достаточно понять несколько не таких уж сложных базовых концепций, чтобы этот самый LINQ был, как говорится, на кончиках пальцев. И мне сейчас его не хватает когда приходится работать с кодом на .NET 2.0
Другое дело, что зрелые зарекомендовавшие себя технологии не становятся хуже от появления новых технологий с новыми возможностями.
Я помню как я сам был недоволен странным синтаксисом LINQ и тем что они вообще городят непонятно что. Оказалось, достаточно понять несколько не таких уж сложных базовых концепций, чтобы этот самый LINQ был, как говорится, на кончиках пальцев. И мне сейчас его не хватает когда приходится работать с кодом на .NET 2.0
Другое дело, что зрелые зарекомендовавшие себя технологии не становятся хуже от появления новых технологий с новыми возможностями.
Вспоминая синглтона Мейерса на C++:
static T& Instance()
{
static T instance;
return instance;
}
Насколько я понимаю сделали именно это)
static T& Instance()
{
static T instance;
return instance;
}
Насколько я понимаю сделали именно это)
неплохо. Если еще обернуть все фабрикой — вообще красота будет
Думаю, ещё полезно было бы иметь аналогичную обёртку для WeekReference, чтобы объект ещё и сам освобождался при необходимости.
В .NET/С# я пожалуй могу считать себя любителем, но кое что кодил и кодю:) После прочтения поста сразу же возник вопросы:
1. Если я правильно понял — это лишь экономия нескольких строк кода?
2. Хотелось бы увидеть конкретные примеры, как это сделать без Lazy и с Lazy, почувствовать, увидеть и поосязать разницу:)
Lazy ведь просто «фишка», востребованность которой крайне невелика. А вот механизмы Reflection и LINQ можно пожалуй назвать в некотором роде инновационными, хотя вокруг них маловато движухи среди .NET программистов в интернете на мой взгляд.
.NET framework вообще очень интересно эволюционирует, мне наиболее интересно наблюдать за постепенным слиянием WPF/.NET3.5 и Silverlight:)
1. Если я правильно понял — это лишь экономия нескольких строк кода?
2. Хотелось бы увидеть конкретные примеры, как это сделать без Lazy и с Lazy, почувствовать, увидеть и поосязать разницу:)
Lazy ведь просто «фишка», востребованность которой крайне невелика. А вот механизмы Reflection и LINQ можно пожалуй назвать в некотором роде инновационными, хотя вокруг них маловато движухи среди .NET программистов в интернете на мой взгляд.
.NET framework вообще очень интересно эволюционирует, мне наиболее интересно наблюдать за постепенным слиянием WPF/.NET3.5 и Silverlight:)
1. Да, но объем экономии зависит от того, нужна потокобезопасность или нет.
2. Мне тоже.
2. Мне тоже.
Это экономия не кода, а ресурсов и/или процессорного времени, улучшает масштабируемость. Позволяет отложить выделение ресурса до момента, когда он реально будет запрошен (будет вызвано свойство Value). А за это время кто-то другой может успеть попользоваться ресурсом, даже если этот ресурс — процессорное время.
Насчет Reflection — это еще в первой версии .net появилось, 10 лет назад. Метаданные и средства доступа к ним это краеугольный камень всей технологии .net. А Linq просто еще не набрал массы юзеров, я вот например только сейчас за него сел, в связи с тотальным обновлением софта и тулзов (WinXP -> Win7, VS2005 -> 2008).
Насчет Reflection — это еще в первой версии .net появилось, 10 лет назад. Метаданные и средства доступа к ним это краеугольный камень всей технологии .net. А Linq просто еще не набрал массы юзеров, я вот например только сейчас за него сел, в связи с тотальным обновлением софта и тулзов (WinXP -> Win7, VS2005 -> 2008).
Откровенно говоря, меня беспокоит кол-во полезного материала в этом посте. Если уж и говорить про
Тот факт что этот пост – перевод, не снимает ответственности за весьма посредственный подход к теме.
Lazy<T>, то нужно по крайней мере упомянуть альтернативные методы реализации, а также «раскрыть тему» потокобезопасности ленивого инициализатора.Тот факт что этот пост – перевод, не снимает ответственности за весьма посредственный подход к теме.
Собственно, я не брал на себя никакой ответственности сделать подход к теме «непосредственным». Оригинальная статья оказалась для меня полезной и интересной, т.к. я узнал о том, что в .NET 4.0 будет такая полезная фишечка. Теперь нужно дождаться релиза.
Если в этой теме кого-то интересует многопоточность, отличие от других реализаций, то я рад, конечно, но это тема для отдельной статьи. Почитайте MSDN, здесь более подробно: msdn.microsoft.com/en-us/library/dd997286%28VS.100%29.aspx
Если в этой теме кого-то интересует многопоточность, отличие от других реализаций, то я рад, конечно, но это тема для отдельной статьи. Почитайте MSDN, здесь более подробно: msdn.microsoft.com/en-us/library/dd997286%28VS.100%29.aspx
Sign up to leave a comment.
Lazy<T>: конструирование объектов по требованию в .NET 4.0