linq to sql vs ado.net - производительность с точки зрения открытого соединения

Question

Мне нужно получить записи из таблицы (около 40 столбцов), обработать каждую запись, вызвать веб-службу для этой записи, дождаться ее ответа и обновить запись в базе данных.

Теперь я вижу 2 варианта.
1. Linq to Sql
2. ADO.Net с типизированным набором данных
(Я оставляю опцию DataReader для всей дополнительной работы, которую я должен сделать.)

2 закрывает соединение вскоре после извлечения данных, я могу обрабатывать данные в автономном режиме и отправлять изменения позже, то есть у меня нет возможности долго держать соединение открытым. С 1, чтобы иметь возможность отправлять изменения в конце, я должен постоянно держать соединение открытым.

Как вы думаете, 2 - это всегда лучший способ, когда изменения необходимо отправить после определенного периода обработки, или я что-то упустил?

Answer 1

Ни Linq to SQL, ни Entity Framework не оставляют соединение открытым, пока вы работаете с извлеченными объектами. Если вы хотите воспользоваться возможностями отслеживания изменений в различных контекстах, вам необходимо сохранить объект контекста в области видимости, но это не означает, что соединение с базой данных остается открытым в течение этого периода. В действительности, соединение открыто только во время итерации результатов (привязки данных) и при вызове SubmitChanges / SaveChanges. В противном случае соединение закрыто.

В этих технологиях используются средства чтения данных ADO.Net и объекты команд под крышками. До сих пор нет концепции открытых курсоров, как у вас было в дни VB6.

Answer 2

L2S или Entity Framework вносят некоторые накладные расходы, но, честно говоря, сэкономленное время того стоит, и всякий раз, когда вы выполняете запрос Linq для ваших объектов, SQL оптимизируется для вас.

Обычная старая ADO.Net - это старая школа - Linq - это то, что нужно.

Answer 3

Обычная старая ADO.Net - это старая школа - Linq - это путь.

Microsoft обслуживает новичков и продает себя массам как «хобби».

LINQ позволяет разработчикам запрашивать источник данных, у которого нет бизнеса, обращающегося к источнику данных.

Обладая глубокими знаниями и умом, достаточными для написания собственного оптимизированного T-SQL, это, пожалуй, желательный навык, а не смехотворный, как в «старой школе».

Как инженер-программист, человек должен двигаться в направлении написания программного обеспечения, которое может работать максимально эффективно и быстро. Весь аргумент «экономии времени разработки» для выбора конструкции более высокого уровня, поскольку ее слишком просто реализовать, говорит о том, насколько дрянной будет работать программа, если ее составить рядом с версией старшего инженера.

Не продавайте самые последние и лучшие предложения, которые делают кодирование «быстрее». Если вы достаточно умны, чтобы сделать это самостоятельно, то сделайте это самостоятельно и избегайте использования синтаксиса LINQ для написания T-SQL.

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

Одним словом, глубокое знание никогда не бывает лишним.