Здравствуйте, Al_Shargorodsky, Вы писали:

A_S>Но ведь синтаксис LINQ можно использовать с любым типом, например, отложенное выполнение:

Нет синтаксиса LINQ, есть:
* Query syntax, который является очень маааленькой и вовсе необязательной частью LINQ-а.
* Query expressions, который является реализацией QS в C#
Другие языки вольны выбирать свой синтаксис QS по усмотрению, либо не использовать его вовсе.

Здравствуйте, samius, Вы писали:

S>Здравствуйте, Al_Shargorodsky, Вы писали:

A_S>>Но ведь синтаксис LINQ можно использовать с любым типом, например, отложенное выполнение:

S>Нет синтаксиса LINQ, есть:
S>* Query syntax, который является очень маааленькой и вовсе необязательной частью LINQ-а.
S>* Query expressions, который является реализацией QS в C#
S>Другие языки вольны выбирать свой синтаксис QS по усмотрению, либо не использовать его вовсе.

согласен. я имел ввиду саму возможность писать в декларативном стиле и ее реализацию, пусть в конкретном языке.

Здравствуйте, Dufrenite, Вы писали:

D>Не очевидно. Венгерская нотация, на мой взгляд, ухудшает читаемость программ.

Я вроде не ратовал за венгерскую нотацию, вы меня с кем-то путаете.

D>Тип переменной должен быть понятен из названия и контекста использования, а дублирование информации только захламляет код.

var customers = GetCustomers()

1. Что не так с названием переменой?
2. Какой тип у customers?

D>Например
D>

D>Dictionary<string, EntityData> nameToEntityData = new Dictionary<string, EntityData>();
D>

D>воспринимается хуже чем
D>

D>var nameToEntityData = new Dictionary<string, EntityData>();
D>

А в приведенном случае информация о типе не теряется, она записана справа от "="

Здравствуйте, D. Mon, Вы писали:

DM>Я так понимаю, вопрос синхронизации с базой возникает, когда мы начинаем эти полученные объекты менять и хотим, чтобы данные менялись в базе. И тут у линка не все гладко.
А просто не надо так делать.
Нужно взять BLToolkit и использовать DML.

Здравствуйте, D. Mon, Вы писали:

Да там не все так однозначно с тех пор, как в SQL появились подзапросы, ссылающиеся на значение полей вышестоящего запроса. Это же "построчное" замыкание, а подзапрос — суть параметризуемый предикат (т.е. ф-ия). Чистейшая, однако, функциональная декомпозиция.

Здравствуйте, Temoto, Вы писали:

T>Да, ваша правда. А вы можете провести чёткую грань между функциональным и декларативным программированием?

Уже провели рядом, но не до конца. ИМХО, практика оперирования ф-иями как первоклассными объектами дает ф-ому программированию удобную возможность для определения параметризуемых "кирпичиков", дальнейшее использование которых очень смахивает на декларативное программирование. Наверно поэтому декларативное все время пытаются приписать ф-ому подходу, но это не правильно.

На самом деле, декларативность программирования — это сугубо относительное понятие. Любой ЯВУ декларативен по отношению к ассемблеру. Мы сразу говорим printf(2*2) — умножь 2 на 2 и выведи на экран, вместо объяснения, в какие регистры чего ложить и какие инструкции вызывать. При любой "правильной" декомпозиции (не обязательно функциональной), вышестоящие уровни демонстрируют по отношению к нижестоящим то самое декларативное программирование. SQL декларативен по отношению к реляционной алгебре, а по отношению к некоему вышестоящему DAL, с т.з. названия этого форума все-таки отвечает на вопрос "как", а не "что", ибо на вопрос "что" относительно данных во всей иерархии отвечает именно DAL. Собственно, как и сами подробности DAL — это ответ на вопрос "как", который возник после рассмотрения некоего ТЗ на систему (самого верхнего "Что").

Здравствуйте, Lloyd, Вы писали:

L>Здравствуйте, Dufrenite, Вы писали:

D>>Не очевидно. Венгерская нотация, на мой взгляд, ухудшает читаемость программ.

L>Я вроде не ратовал за венгерскую нотацию, вы меня с кем-то путаете.

D>>Тип переменной должен быть понятен из названия и контекста использования, а дублирование информации только захламляет код.

L>

L>var customers = GetCustomers()
L>

L>1. Что не так с названием переменой?
L>2. Какой тип у customers?

IEnumerable<Customer> ?

Здравствуйте, Jack128, Вы писали:

D>>>Тип переменной должен быть понятен из названия и контекста использования, а дублирование информации только захламляет код.

L>>

L>>var customers = GetCustomers()
L>>

L>>1. Что не так с названием переменой?
L>>2. Какой тип у customers?

J>IEnumerable<Customer> ?

С чего ты взял? Почему не Customer[], Collection<Customer>, HashSet<Customer> или List<Customer>?

Здравствуйте, Lloyd, Вы писали:

L>Здравствуйте, Jack128, Вы писали:

D>>>>Тип переменной должен быть понятен из названия и контекста использования, а дублирование информации только захламляет код.

L>>>

L>>>var customers = GetCustomers()
L>>>

L>>>1. Что не так с названием переменой?
L>>>2. Какой тип у customers?

J>>IEnumerable<Customer> ?

L>С чего ты взял? Почему не Customer[], Collection<Customer>, HashSet<Customer> или List<Customer>?

А какая разница? Тока ближе к практике, пожалуйста.

Здравствуйте, D. Mon, Вы писали:

DM>Я так понимаю, вопрос синхронизации с базой возникает, когда мы начинаем эти полученные объекты менять и хотим, чтобы данные менялись в базе. И тут у линка не все гладко.

Ты не верно понимаешь. У лика в общем вообще вопрос изменения БД не оговорен. То как он реализован и реализован ли вообще решает конкретный линк-провайдер. В частности есть такой провайдер BLToolkit (созданный одним из основателей нашего сайта — IT) который решает данную проблему путем предоставления CRUD/DML-операций аналогичных запросам INSERT/DELETE/UPDATE из SQL.

Другие провайдеры используют идеологию оптимистических блокировок и так же не нуждаются в синхронизации. Хотя лично мне эта идея не нравится.

Есть пожалуй только один провайдер (для NHibernate) который занимается кэшированием и прочей фигней. Ну, так это потому, что это провайдер к объектному-персистеру который использует идеологию, на мой взгляд, в корне порочную.

Здравствуйте, Jack128, Вы писали:

J>>>IEnumerable<Customer> ?

L>>С чего ты взял?

Я так понимаю, ответа на вопрос у вас нет?

L>>Почему не Customer[], Collection<Customer>, HashSet<Customer> или List<Customer>?

J>А какая разница? Тока ближе к практике, пожалуйста.

Например, вот в таком коде:

for(int i=0; i < customers.Count(); i++) {
  Consolw.WriteLine("{0}: {1}", i, customers.ElementAt(i).Name);
}

Если customers — IEnumerable, полученный из linq-овского запроса, то на 1000 customer-ах получили 2000 запросов в базу. Если просто лист — то ни одного.

Здравствуйте, Lloyd, Вы писали:

L>Если customers — IEnumerable, полученный из linq-овского запроса, то на 1000 customer-ах получили 2000 запросов в базу. Если просто лист — то ни одного.

Это конечно большая проблема! А как ты её решаешь, когда у тебя не List<Customer>, а, например, List<<>f__AnonymousTypef<int,string>>?

Здравствуйте, IT, Вы писали:

L>>Если customers — IEnumerable, полученный из linq-овского запроса, то на 1000 customer-ах получили 2000 запросов в базу. Если просто лист — то ни одного.

IT>Это конечно большая проблема! А как ты её решаешь, когда у тебя не List<Customer>, а, например, List<<>f__AnonymousTypef<int,string>>?

Если ты мне расскажешь, как мне из метода получить List<<>f__AnonymousTypef<int,string>>, я обязательно отвечу на твой вопрос.

Здравствуйте, Lloyd, Вы писали:

L>>>Если customers — IEnumerable, полученный из linq-овского запроса, то на 1000 customer-ах получили 2000 запросов в базу. Если просто лист — то ни одного.

IT>>Это конечно большая проблема! А как ты её решаешь, когда у тебя не List<Customer>, а, например, List<<>f__AnonymousTypef<int,string>>?

L>Если ты мне расскажешь, как мне из метода получить List<<>f__AnonymousTypef<int,string>>, я обязательно отвечу на твой вопрос.

var arr  = new[] { new { String = "", Int = 1 } };
var list = arr.ToList();

Здравствуйте, Lloyd, Вы писали:

L>>>Если customers — IEnumerable, полученный из linq-овского запроса, то на 1000 customer-ах получили 2000 запросов в базу. Если просто лист — то ни одного.
IT>>Это конечно большая проблема! А как ты её решаешь, когда у тебя не List<Customer>, а, например, List<<>f__AnonymousTypef<int,string>>?
L>Если ты мне расскажешь, как мне из метода получить List<<>f__AnonymousTypef<int,string>>, я обязательно отвечу на твой вопрос.

Могу ещё рассказать, как получить IEnumerable (ты будешь думать о 2000 запросах в базу), а запросов будет ни одного. Рассказывать или ты сам?

Здравствуйте, IT, Вы писали:

L>>Если ты мне расскажешь, как мне из метода получить List<<>f__AnonymousTypef<int,string>>, я обязательно отвечу на твой вопрос.

IT>

IT>var arr  = new[] { new { String = "", Int = 1 } };
IT>var list = arr.ToList();
IT>

Варианты, ToList, ToArray и т.д. не относятся к случаям, когда тип не указан, т.к. тип-таки фигурирует (List, Array).
Кроме того, тип переменных анонимного типа легко выводится из контекста.

Здравствуйте, IT, Вы писали:

L>>Если ты мне расскажешь, как мне из метода получить List<<>f__AnonymousTypef<int,string>>, я обязательно отвечу на твой вопрос.

IT>Могу ещё рассказать, как получить IEnumerable (ты будешь думать о 2000 запросах в базу), а запросов будет ни одного. Рассказывать или ты сам?

Нет, не надо.
Я не собираюсь вас убежать в чем либо, у меня есть свои предпочтения в использовании var-а и я им следую. Так же я знаю преимущества и недостатки обоих подходов. Не тратьте свое время на повтороение того, что было уже обсосано не по одному десятку раз.

Удачи.

Здравствуйте, Lloyd, Вы писали:

L>>>Если ты мне расскажешь, как мне из метода получить List<<>f__AnonymousTypef<int,string>>, я обязательно отвечу на твой вопрос.
L>Варианты, ToList, ToArray и т.д. не относятся к случаям, когда тип не указан, т.к. тип-таки фигурирует (List, Array).
L>Кроме того, тип переменных анонимного типа легко выводится из контекста.

Ну ты упёртый.

List<T> GetCustomers<T>(T[] arr)
{
    return arr.ToList();
}

var arr  = new[] { new { String = "", Int = 1 } };
var list = GetCustomers(arr);

Теперь в методе GetCustomers меняем тип возвращемого значения на IEnumerable<T> и, 'О, чудо!', получаем IEnumerable, а запросов к базе ни одного!

Здравствуйте, IT, Вы писали:

L>>Кроме того, тип переменных анонимного типа легко выводится из контекста.

IT>Ну ты упёртый.

Да ваще, баран полный. Втемяшу себе в голову какую-нить глупость и потом хожу и на потеху публике выставляюсь полным дураком.
Чё с таким говорить, бесполезно же.

IT>Теперь в методе GetCustomers меняем тип возвращемого значения на IEnumerable<T> и, 'О, чудо!', получаем IEnumerable, а запросов к базе ни одного!

Вы правда-правда такие методы пишете или вы просто задались целью опровегнуть мое утверждение про анонимные типы?

Здравствуйте, Lloyd, Вы писали:

L>Вы правда-правда такие методы пишете или вы просто задались целью опровегнуть мое утверждение про анонимные типы?

Мы пишем разные методы, но никогда при этом не руководствуемся тем, будет ли лучше ставить var перед получением значения из этого метода или полный тип.