Результаты поиска

Изучение LINQ

Обзор

Одна из вещей, о которых я много спрашивал на этом сайте, - это LINQ . Вопросы, которые я задавал, были широкими и разнообразными, и часто за ними не было большого контекста. Поэтому в попытке закрепить знания, которые я приобрел на Linq, я публикую этот вопрос с целью поддержания и обновления его дополнительной информацией по мере того, как я продолжаю изучать LINQ.

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

Что такое LINQ?

От MSDN :

Проект LINQ-это кодовое имя для a набор расширений для .NET Рамки, которые охватывают язык-интегрированный запрос, набор и операции преобразования. Он расширяет C# и Visual Basic с родным языком синтаксис для запросов и предоставляет класс библиотеки, чтобы воспользоваться этими преимуществами способности.

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

Какие ароматы LINQ существуют?

В настоящее время существует несколько различных поставщиков LINQ, предоставляемых корпорацией Майкрософт:

• Linq к объектам , что позволяет выполнять запросы к любому объекту IEnumerable.
• От Linq до SQL , что позволяет выполнять запросы к базе данных в объектно-ориентированном виде.
• От Linq до XML , что позволяет запрашивать, загружать, проверять, сериализовывать и манипулировать документами XML.
• Linq to Entities по предложению Андрея
• Linq к набору данных

Есть довольно много других, многие из которых перечислены здесь .

Какие же это преимущества?

• Стандартизированный способ запроса нескольких источников данных
• Безопасность запросов во время компиляции
• Оптимизированный способ выполнения операций на основе наборов для объектов в памяти
• Возможность отладки запросов

Так что же мне делать с LINQ?

Chook предоставляет способ вывода CSV файлов
Джефф показывает, как удалить дубликаты из массива
Боб получает четкий упорядоченный список из datatable
Марксидад показывает, как сортировать массив
Дана получает помощь в реализации быстрой сортировки с помощью Linq

С чего начать?

Краткое содержание ссылок из вопроса GateKiller приведено ниже :
Скотт Гатри приводит вступление к Linq в своем блоге
Обзор LINQ на MSDN

ChrisAnnODell предлагает проверить

Зачем нам нужны объекты сущностей?

Мне действительно нужно увидеть честные, вдумчивые дебаты о достоинствах принятой в настоящее время парадигмы проектирования корпоративных приложений .

Я не убежден, что сущностные объекты должны существовать.

Под объектами сущностей я подразумеваю типичные вещи, которые мы обычно создаем для наших приложений, например "Person", "Account", "Order" и т. д.

Моя нынешняя философия дизайна такова:

• Весь доступ к базе данных должен осуществляться с помощью хранимых процедур.
• Всякий раз, когда вам нужны данные, вызовите хранимую процедуру и выполните итерацию по SqlDataReader или строкам в DataTable

(Примечание: Я также построил корпоративные приложения с Java EE, java людьми, пожалуйста, замените экввалентные для моих .NET примеров)

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

Я не строю игрушки. Я говорю о больших транзакционных приложениях большого объема, развернутых на нескольких машинах. Веб-приложения, службы windows, веб-службы, b2b-взаимодействие, вы называете это.

Я использовал или картографы. Я уже написал несколько таких писем. Я использовал стек Java EE, CSLA и несколько других эквивалентов. Я не только использовал их, но и активно разрабатывал и поддерживал эти приложения в производственных средах.

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

Рассмотрим этот простой пример: вы получаете вызов службы поддержки по поводу определенной страницы в вашем приложении, которая работает неправильно, возможно, одно из полей не сохраняется, как это должно быть. С моей моделью разработчик, назначенный для поиска проблемы, открывает ровно 3 файла . Файл ASPX, ASPX.CS и SQL с сохраненной процедурой. Проблема, которая может быть пропущенным параметром для вызова хранимой процедуры, требует нескольких минут для решения. Но с любой моделью сущностей вы неизменно запускаете отладчик, начинаете шагать по коду, и в конечном итоге вы можете получить файлы 15-20, открытые в Visual Studio. К тому времени, когда вы спуститесь в самый низ стопки, вы забудете, с чего начали. Мы можем только держать так много вещей в наших головах одновременно. Программное обеспечение невероятно сложное, без добавления каких-либо ненужных слоев.

Сложность разработки и устранение неполадок - это только одна сторона моей проблемы.

Теперь поговорим о масштабируемости.

Делают ли разработчики понимаете ли вы, что каждый раз, когда они пишут или изменяют какой-либо код, взаимодействующий с базой данных, им нужно провести тророговый анализ точного воздействия на базу данных? И не просто копия разработки, я имею в виду имитацию производства, так что вы можете видеть, что дополнительный столбец, который вам теперь требуется для вашего объекта, просто аннулировал текущий план запроса, и отчет, который был запущен за 1 секунду, теперь займет 2 минуты только потому, что вы добавили один столбец в список выбора? И получается, что индекс, который вам теперь требуется, настолько велик, что DBA придется изменить физический макет ваших файлов?

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

Я вовсе не фанатик. Меня можно убедить, если я ошибаюсь, и, возможно, я ошибаюсь, поскольку существует такой сильный толчок к Linq, чтобы Sql, ADO.NET EF, Hibernate, Java EE, и т.д. Пожалуйста, продумайте свои ответы, если я что-то упускаю, я действительно хочу знать, что это такое, и почему я должен изменить свое мышление.

[Редактировать ]

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

Вероятно, мне следовало бы более четко объяснить, что я говорю о корпоративных приложениях. Я действительно не могу комментировать, скажем, игру, которая работает на чьем-то рабочем столе или мобильном приложении.

Одна вещь, которую я должен поставить здесь наверху в ответ на несколько подобных ответов: ортогональность и разделение проблем часто цитируются в качестве причин для перехода entity/ORM. хранимые процедуры, на мой взгляд, являются лучшим примером разделения проблем, который я могу придумать. Если вы запретите любой другой доступ к базе данных, кроме как через хранимые процедуры, вы теоретически можете перестроить всю свою модель данных и не нарушать никакого кода, пока вы поддерживаете входы и выходы хранимых процедур. Они являются прекрасным примером программирования по контракту (просто до тех пор, пока вы избегаете "select *" и документируете результирующие наборы).

Спросите кого-нибудь, кто давно работает в этой отрасли и работает с долгоживущими приложениями: сколько слоев приложений и UI появилось и исчезло за время существования базы данных? Насколько сложно настроить и рефакторировать базу данных, когда есть 4 или 5 различных уровней сохраняемости, генерирующих SQL для получения данных? Ты ничего не можешь изменить! ORMs или любой код, который генерирует SQL, блокирует вашу базу данных в камне .