ASP.NET MVC Framework - [14]
>List
>a.Add(3) ;
>a.Add(12) ;
>a.Add(-1);
>List
>foreach (int item in a)
>{
> if (item >= 0)
> positive.Add(item) ;
>}
То, для чего обычно требовалось несколько строк кода, циклы и условия, теперь можно записать одним выражением в одной строке. Это и есть суть LINQ. В языке C# существует альтернативный вариант записи LINQ-выражений, который выглядит так:
>List
> from x in a
> where x >= 0
> select x
> ).ToList ();
Как можно заметить, этот вариант во многом похож на синтаксис SQL-запросов. Что и не удивительно, поскольку этот вариант разрабатывался с учетом потребности в написании таких запросов архитекторами SQL-баз данных и специалистов, привыкших к подобному синтаксису. В своих проектах вы можете использовать любой из вариантов либо смешивать их друг с другом. Как показывает практика, каждый из них предпочтителен в разных конкретных случаях.
Рассмотренный пример задействует в себе механизм LINQ для объектов, который позволяет оперировать с коллекциями и другими стандартными наборами данных. Но кроме него огромное значение при работе с данными играют два других LINQ-провайдера: LINQ для SQL и LINQ для сущностей, которые призваны поддержать работу с двумя отдельными друг от друга ORM: LINQ для SQL и Entity Framework.
LINQ для SQL
LINQ для SQL является встроенным в .NET Framework механизмом, что отличает его от появившегося немного позднее Entity Framework. Благодаря этой встроенной поддержке и удобным инструментам мэппинга базы данных, LINQ для SQL получил очень широкое распространение. Способствовало этому также простота работы с ORM и низкий порог вхождения для любого разработчика. Кроме того, для создания ORM-базы данных с помощью LINQ для SQL не требуется писать ни строчки кода (хотя такая возможность и присутствует). В помощь разработчикам был предложен мастер создания модели данных, который формирует особый DBML-файл и файл с необходимыми для мэппинга классами. От разработчика требуется только указать подключение к БД и выбрать необходимые таблицы, все остальное мастер берет на себя (рис. 3.2 и 3.3).
Дальнейшее использование полученной модели данных столь же простое. Разработчику необходимо создать контекст базы данных, внести изменения и подтвердить их. Продемонстрируем это на примере:
>protected void DoSomethingWithCustomer(Guid someCustomerld)
>{
> MyDatabaseDataContext db = new MyDatabaseDataContext();
> var customer = db.Customers.SingleOrDefault(
> x => x.customerId == someCustomerId);
> if (customer != null)
> {
> customer.name = "Заказчик 1";
> db.SubmitChanges();
> }
>}
Рис. 3.2. Окно создания модели LINQ для SQL
Рис. 3.3. Добавление в LINQ для SQL таблицы Customer
Здесь создается контекст базы данных >MyDatabaseDataContext, ищется пользователь с определенным идентификатором >someCustomerid, если он найден, у него меняется наименование на Заказчик 1 и изменения вносятся в базу данных вызовом метода >Submitchanges. Такой же код, но с использованием механизма ADO.NET, приведен в следующем фрагменте. Вы сами можете сравнить оба способа по требуемому количеству кода и простоте:
>protected void DoSomethingWithCustomer(Guid someCustomerId)
>{
> using (SqlConnection conn = new SqlConnection(@"
> Data Source=localhost;
> Initial Catalog=BookMVC; Integrated Security=True">))
> {
> conn.Open();
> SqlCommand cmd = new SqlCommand(@"
> SELECT * FROM Customers
> WHERE customerId = @customerId", conn);
> cmd.Parameters.Add(
> new SqlParameter("customerId", someCustomerId));
> SqlDataReader reader = cmd.ExecuteReader();
> if (reader.Read())
> {
> SqlCommand updateCmd = new SqlCommand(@"
> UPDATE Customers SET name = @name
> WHERE customerId = @customerId", conn);
> updateCmd.Parameters.Add(
> new SqlParameter(''name", "Заказчик 1"));
> updateCmd.Parameters .Add(
> new SqlParameter("customerId", someCustomerId));
> updateCmd.ExecuteNonQuery();
> }
> reader.Close();
> }
>}
Простота LINQ для SQL послужила его широкой распространенности. Но вместе с тем, в LINQ для SQL существуют и свои минусы. Во-первых, не так редки ситуации, когда неверно или некорректно построенное разработчиком LINQ-выражение приводит к потерям в производительности, к выборке лишних данных, к расходу памяти. Кроме того, в LINQ для SQL отсутствуют такие механизмы, как прозрачный мэппинг таблиц, связанных друг с другом через промежуточную таблицу отношением "многие-ко-многим". Многие разработчики на веб-сайтах, блогах и других сетевых ресурсах критиковали LINQ для SQL как ORM Framework за недостатки, как в производительности, так и в функциональном плане. Некоторые из них утверждают, что LINQ для SQL вовсе нельзя считать полноценным ORM Framework, справедливо замечая, что в нем нет возможности, например, создавать комплексные типы или производить наследование типов. По сути своей LINQ для SQL скорее представляет собой строго типизированное представление базы данных SQL Server, чем полноценный механизм ORM. Еще один недостаток LINQ для SQL заключается в его привязке к SQL Server, как к единственно возможному источнику данных. Безусловно, для ORM это ограничение является огромным недостатком, поскольку на рынке представлено свыше десятка разнообразных баз данных.
