Здравствуйте, IT, Вы писали:
L>>Вы правда-правда такие методы пишете или вы просто задались целью опровегнуть мое утверждение про анонимные типы?
IT>Мы пишем разные методы, но никогда при этом не руководствуемся тем, будет ли лучше ставить var перед получением значения из этого метода или полный тип.
И все-таки ответьте на вопрос, пишете ли вы такие методы?
Здравствуйте, IT, Вы писали:
M>>О чём я имею "весьма смутное и отдалённое понятие"? О промышленной разработке "типичных" проектов? Не соглашусь. О LINQ? Пожалуй да. Ну дык в том виде в каком её подают я не вижу ей применения для своих задач. Ниже типичный пример использования LINQ. Вот скажите, вам в самом деле часто приходится работать с такими ArrayList'ами? Как правило же все эти данные лежат в БД и дергаются либо тем же SQL, либо HQL.
IT>[c#] IT>public class Student IT>{ IT> public int StudentID { get; set; }
... IT> [Association(ThisKey = "StudentID", OtherKey = "StudentID")] IT> public Score[] Scores { get; set; } IT>}
... IT>Генерируемый SQL (Sybase):
IT>
То есть ЛИНК — это универсальный интерфейс для работы реляционными (БД), иерархическими (XML) данными и стандартными коллекциями в памяти. Так? Он позиционируется как замена XPath, ORM-библиотек, а также как удобная тулза для стандартных коллекций внутри программы на C#. Так? Ну тогда идея действительно масштабная и актуальная. Лишь бы баланс между логической стройностью , простотой и возможностями был приемлемым. Кстати, там под низом полноценный ORM-движок есть или всё просто на уровне запрос/ответ? Я имею ввиду разруливание циклических ссылок, кэширование, пакетное обновление, ленивую загрузку. Датасеты наконец сдохнут?
Здравствуйте, Dufrenite, Вы писали:
M>>Я в промышленном программировании уже 2 года как не появлялся, так что мои представления могут быть несколько устаревшими. Но если взять "типичный" проект с SQL БД, то действительно не очень понятно зачем мне ещё и LINQ. Ведь практически все объекты с которыми я работаю, лежат в БД и оттуда их можно спокойно выдернуть SQL запросом, который отработает на сервере, который всё соптимизирует, закэширует и т. д. Зачем мне самому держать коллекции, к которым потом обращаться через заново изобретенный SQL и не забывать синхронизировать с базой? Нет, конечно иногда приходится, но не так часто, и этого лучше избегать.
D>То, что вы хотите сказать вполне разумно, но. Не базой данных единой жив программист. Я не буду строить из себя мега-математика и эксперта по теории множеств, а скажу с точки зрения обычного разработчика. LINQ это мега удобно при работе с коллекциями. Например, там где обычно надо написать несколько вложенных циклов и задействовать несколько промежуточных переменных LINQ позволяет обойтись одним запросом или простой цепочкой вызовов (кому как нравится). D>Код получается короче и понятней (проверено). Свободы больше: хочу циклы пишу, хочу запросы. Как проще и понятней получается тот способ и выбираю.
Вот меня тоже заинтересовала именно эта фишка. Я в последнее время пишу всякие числодробилки на С/С++ и мне такой инструмен был бы очень кстати. Потому я и удивился, что он появился именно в промышленном программировании (бизнес-приложений), где, насколько я помню, он не особо то нужен был.
Здравствуйте, Lloyd, Вы писали:
L>>>Вы правда-правда такие методы пишете или вы просто задались целью опровегнуть мое утверждение про анонимные типы? IT>>Мы пишем разные методы, но никогда при этом не руководствуемся тем, будет ли лучше ставить var перед получением значения из этого метода или полный тип. L>И все-таки ответьте на вопрос, пишете ли вы такие методы?
Всякие пишем. Я не вижу никаких проблем в написании методов с таким поведением. А в чём твоя проблема?
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, Mazay, Вы писали:
M>То есть ЛИНК — это универсальный интерфейс для работы реляционными (БД), иерархическими (XML) данными и стандартными коллекциями в памяти. Так?
Примерно.
M>Он позиционируется как замена XPath, ORM-библиотек, а также как удобная тулза для стандартных коллекций внутри программы на C#. Так?
Не замена, а скорее дополнение.
M>Ну тогда идея действительно масштабная и актуальная. Лишь бы баланс между логической стройностью , простотой и возможностями был приемлемым. Кстати, там под низом полноценный ORM-движок есть или всё просто на уровне запрос/ответ? Я имею ввиду разруливание циклических ссылок, кэширование, пакетное обновление, ленивую загрузку. Датасеты наконец сдохнут?
Это пример из BLToolkit, а он не позиционируется как тяжёлый ORM с полноценным Entity Service. Но можно взять тот же Entity Framework. В нём всё это есть.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
L>>И все-таки ответьте на вопрос, пишете ли вы такие методы?
IT> Всякие пишем. Я не вижу никаких проблем в написании методов с таким поведением.
L>1. Что не так с названием переменой? L>2. Какой тип у customers?
Если используем Visual Studio и надо узнать точный тип, то для этой цели есть контекстная подсказка. Мне лично хватает.
Если IDE нет, то пускаем пулю в лоб, меняем профессию или ищем объявление GetCustomers(). Как то так.
Здравствуйте, Dufrenite, Вы писали:
L>>1. Что не так с названием переменой? L>>2. Какой тип у customers?
D>Если используем Visual Studio и надо узнать точный тип, то для этой цели есть контекстная подсказка. Мне лично хватает.
В Visual Studio не везде есть подсказка: ее нет в Annotate, нет в diff-ах, stacktrace-ах, логах.
D>Если IDE нет, то пускаем пулю в лоб, меняем профессию или ищем объявление GetCustomers(). Как то так.
Это конечно ваш выбор, но я предпочитаю более гуманный вариант — указывать типы, там где они нужны/возможны.
Здравствуйте, Mazay, Вы писали:
M>Вот меня тоже заинтересовала именно эта фишка. Я в последнее время пишу всякие числодробилки на С/С++ и мне такой инструмен был бы очень кстати.
Да, мне его тоже в C++ не хватает.
M>Потому я и удивился, что он появился именно в промышленном программировании (бизнес-приложений), где, насколько я помню, он не особо то нужен был.
Я бизнес приложениями не занимаюсь. Использую линк в редакторах игр и DSL компиляторах.
Хотя уверен, что в бизнес приложениях он тоже весьма удобен.
Здравствуйте, Lloyd, Вы писали:
IT>> Всякие пишем. Я не вижу никаких проблем в написании методов с таким поведением. L>А можно пример такого метода из жизни?
Например, есть метод, который получает текстовый поток и дробит его на строки, на выходе IEnumerable<string>. Затем есть второй метод, который каждую строчку преобразует в массив строк, использую символ разделитель. На выходе IEnumrable<string[]>. Следующий метод валидирует данные и преобразует массив в некоторый тип. На выходе IEnumerable<T>. Сигнатура такого метода примерно такая:
Здравствуйте, IT, Вы писали:
IT>Например, есть метод, который получает текстовый поток и дробит его на строки, на выходе IEnumerable<string>. Затем есть второй метод, который каждую строчку преобразует в массив строк, использую символ разделитель. На выходе IEnumrable<string[]>. Следующий метод валидирует данные и преобразует массив в некоторый тип. На выходе IEnumerable<T>. Сигнатура такого метода примерно такая:
IT>
Не совсем понимаю, что этот код призван показать. Воткните вызов этого метода в код, приведенный мной выше, и ограбете некорректное поведение. В случае Linq2Sql-я буде еще хуже — он просто начнет по-честному фигачить кучу запросов в базу, тем самым запрятав проблему.
Здравствуйте, Lloyd, Вы писали:
L>Не совсем понимаю, что этот код призван показать. Воткните вызов этого метода в код, приведенный мной выше, и ограбете некорректное поведение. В случае Linq2Sql-я буде еще хуже — он просто начнет по-честному фигачить кучу запросов в базу, тем самым запрятав проблему.
Не огребём. Этот код не ходит в базу вообще. У тебя какое-то странное понимание IEnumerable. Если это IEnumerable, то он обязательно должен ходить в базу IList, между прочим тоже IEnumerable.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, Mazay, Вы писали:
M>Вот меня тоже заинтересовала именно эта фишка. Я в последнее время пишу всякие числодробилки на С/С++ и мне такой инструмен был бы очень кстати. Потому я и удивился, что он появился именно в промышленном программировании (бизнес-приложений), где, насколько я помню, он не особо то нужен был.
В STL есть близкие по духу решения. С поправкой на реалии С++
Здравствуйте, IT, Вы писали:
L>>Не совсем понимаю, что этот код призван показать. Воткните вызов этого метода в код, приведенный мной выше, и ограбете некорректное поведение. В случае Linq2Sql-я буде еще хуже — он просто начнет по-честному фигачить кучу запросов в базу, тем самым запрятав проблему.
IT>Не огребём. Этот код не ходит в базу вообще.
Огребем. Если я понял тебя правильно, ты сцепляешь приведенные методы в цепочку и в конечном итоге у тебя будет происходить чтение stream-а. Если ты "прокрутил" последний enumerable до конца, то стрим у тебя будет спозизионирован на конец. Повторное чтение приведет либо к исключению, либо к пустой коллекции на выходе.
IT>У тебя какое-то странное понимание IEnumerable. Если это IEnumerable, то он обязательно должен ходить в базу
У меня нет такого понимания IEnumerable, не придумывай.
Здравствуйте, Mystic, Вы писали:
M>Сравнительно сложен в изучении и понимании при том, что существующие методы решения таких задач всех устраивают.
Каких задач? Меня интересует твой взгляд.
Здравствуйте, Lloyd, Вы писали:
L>В Visual Studio не везде есть подсказка: ее нет в Annotate, нет в diff-ах, stacktrace-ах, логах. L>Это конечно ваш выбор, но я предпочитаю более гуманный вариант — указывать типы, там где они нужны/возможны.
Согласен. Именно поэтому я говорил о контексте. Если из контекста тип переменной не очевиден, то лучше его явно указать.
Если вернуться к изначальному примеру.
Контекст может быть таким:
var customers = GetCustomers();
foreach (var customer in customers)
{
Output(customer.Name);
}
Здесь не нужен микроскоп чтобы понять, что customers это как минимум IEnumerable<Customer>. В большинстве случаев этого будет достаточно.
Или так:
var customers = GetCustomers();
for (int i = 0; i < customers.Length; ++i)
{
Output(customers[i].Name);
}
Отсюда очевидно, что customers это массив.
Еще один аргумент: много языков не имеют строгой типизации, однако их активно используют и отказываться не собираются.
Здравствуйте, Dufrenite, Вы писали:
D>Согласен. Именно поэтому я говорил о контексте. Если из контекста тип переменной не очевиден, то лучше его явно указать.
D>Если вернуться к изначальному примеру. D>Контекст может быть таким:
Если вы попытаетесь продумать все контескты, то очень быстро захлебнетесь во множестве вариантов и правила выбора быстро станут очень сложными (а то и противоречивыми). Сложные правила — не работают.
Мое правило — простое и следовательно лучше.
Здравствуйте, Lloyd, Вы писали:
L>Огребем. Если я понял тебя правильно, ты сцепляешь приведенные методы в цепочку и в конечном итоге у тебя будет происходить чтение stream-а. Если ты "прокрутил" последний enumerable до конца, то стрим у тебя будет спозизионирован на конец. Повторное чтение приведет либо к исключению, либо к пустой коллекции на выходе.
Влезу в ваш диалог. Ленивое поведение в данном случае является потенциально опасным. Лучше в стандарте кодирования явно прописать обязательное приведение результата запроса к коллекции (если в решении не требуется именно ленивость).
Если нам не помогут, то мы тоже никого не пощадим.
