Comments 18
отличный метод, использующий как плюсы LinqToSql (автоматизация по работе с хранимыми процедурами) так и работающий в разы быстрее стандартных вызовов.
А по мне как то всё это необычно, непривычно и сложно. Я наверное буду по прежнему писать запросы в БД сам, чтобы иметь возможность контролировать и оптимизировать в случае чего, а не полагаться на Linq, чтобы потом неделю разбираться где он тормозит формируя неправильнае запросы и что мне нужно построить в индексах чтобы этого не случилось.
ИМХО Linq конечно умный, иногда удобный, но не взлетит.
ИМХО Linq конечно умный, иногда удобный, но не взлетит.
Я наверное отстал от жизни или не понял в чем фишка. Что-бы вызвать хранимую процедуру из БД надо столько кода написать… Поясните пожалуйста?
На выходе получим объект с заполненными полями.
Есть 2 подхода в программировании — типизированный и нетипизированный. .NET Framework является типизированной платформой для программирования. Типизированный подход имеет главный плюс — безопасность и управляемость кода, а именно:
— refactoring
— intellisence
— проверки на уровне компиляции (в том числе страховка от невалидных вызовов)
— быстрота использования готового кода
— самодокументированность.
Поэтому в данном примере необходимо было продекларировать типизированный прототип результата и типизированный прототип хранимой процедуры. В помощь декларирования типов в примере были использованы атрибуты — это воистину магия .NET Framework'а. :))) Именно поэтому код в примере выглядит «раздуто».
— refactoring
— intellisence
— проверки на уровне компиляции (в том числе страховка от невалидных вызовов)
— быстрота использования готового кода
— самодокументированность.
Поэтому в данном примере необходимо было продекларировать типизированный прототип результата и типизированный прототип хранимой процедуры. В помощь декларирования типов в примере были использованы атрибуты — это воистину магия .NET Framework'а. :))) Именно поэтому код в примере выглядит «раздуто».
Уж простите великодушно, но жутко неграмотная мешанина у вас получается.
«Типизированным и нетипизированным» может быть исключительно язык программирования, а никак не «подход» и не «платформа».
«Безопасность», применительно к языкам программирования, не значит вообще ничего. «Типобезопасность» же — вполне. «Управляемость» имеет значение, сильно отличающееся от того, которое вы в него вкладываете. Управляемым может быть код. «Быстрота» к типизированности имеет лишь опосредованное отношение. Как, впрочем, и «самодокументироемость».
«Продекларировать типизированный прототип результата» и «… функции» — это совсем страшно. «Прототипов» в CLR отродясь не было. В коде же банально определяется класс результата и пишется функция-адаптер.
«Типизированным и нетипизированным» может быть исключительно язык программирования, а никак не «подход» и не «платформа».
«Безопасность», применительно к языкам программирования, не значит вообще ничего. «Типобезопасность» же — вполне. «Управляемость» имеет значение, сильно отличающееся от того, которое вы в него вкладываете. Управляемым может быть код. «Быстрота» к типизированности имеет лишь опосредованное отношение. Как, впрочем, и «самодокументироемость».
«Продекларировать типизированный прототип результата» и «… функции» — это совсем страшно. «Прототипов» в CLR отродясь не было. В коде же банально определяется класс результата и пишется функция-адаптер.
Если интересны последние разработки Майкрософта для работы с БД, обратите вниимание на Entity Framework и на ADO.NET Data Services. Две эти технологии стали частью релиза sp1. Чем интересна последная, так это возможностью делать запросы к базе через http строку (http://localhost/customers(2)
После ознакомления может появиться неясность где использовать Linq to SQL, а где Entity Framework, приведу небольшие пояснения:
можно почитать тут
ну и все остальное взято здесь
После ознакомления может появиться неясность где использовать Linq to SQL, а где Entity Framework, приведу небольшие пояснения:
If you want the added security of insulation and loose coupling from the underlying database schema to make your object model more resilient to change, use the Entity Framework
If you find that you need the features of entity inheritance and entity composition, use the Entity Framework
If you already have a large DLINQ codebase (oddly enough, I do) that is running just fine without entities, you probably don't need to spend the time to refactor out DLINQ to replace it with L2E.
If you want to run LINQ queries against an object model, but your object model is a 1:1 mirror of the tables in your database, you probably don't need the EF.
Not included in the chart above, ADO.NET vNext has a powerful «client-views» engine which will only get better with time and is just more incentive for adopting the new stuff.
можно почитать тут
ну и все остальное взято здесь
weblogs.asp.net/scottgu/archive/2007/08/16/linq-to-sql-part-6-retrieving-data-using-stored-procedures.aspx
weblogs.asp.net/scottgu/archive/2007/08/23/linq-to-sql-part-7-updating-our-database-using-stored-procedures.aspx
Вот замечательные статьй на эту тему, рекомендую ознакомиться.
weblogs.asp.net/scottgu/archive/2007/08/23/linq-to-sql-part-7-updating-our-database-using-stored-procedures.aspx
Вот замечательные статьй на эту тему, рекомендую ознакомиться.
Страшная вещь. Сравните с:
Использование:
Все это BLToolkit.
public abstract class ItemAccessor : DataAccessor<Item>
{
[SprocName("sp_getItems")]
public Item GetItem(string @query);
}
class Item
{
public long Id { get; set; }
public string Name { get; set; }
public string Description { get; set; }
}
Использование:
var itemAccessor = DataAccessor.CreateInstance<ItemAccessor>();
var item = itemAccessor.GetItem("<query><id>12</id><id>13</id></query>");
Все это BLToolkit.
Да согласен, синтаксис более сложный, но я оцениваю технологию Linq вцелом. «Ручное» использование хранимых процедур — это всего лишь 1 аспект общего функционала (это тонкая оптимизация). А сложности синтаксиса декларации вызова хранимой процедуры — плата за возможность «тонкой настройки» и мою уверенность в том что код будет работать именно так как нужно.
Для большинства задачь достаточно того что умеет делать дизайнер Visual Studio
Кроме того, есть гораздо более простой синтаксис вызова команд:
using(var context = new DataContext(«ConnectionString»))
return this.ExecuteQuery(«exec sp_getItems @query», «12</12>»);
…
class Item
{
public long Id { get; set; }
public string Name { get; set; }
public string Description { get; set; }
}
А что касается самой библиотеки BLToolkit — то она не предполагает наличия никакого дизайнера, а значит 90% всех задачь ее пользователь вынужден писать самостоятельно.
Еще важный момент — ключевое слово abstract перед каждым наследником класса ItemAccessor говорит о том что в библиотеке используется динамическая компиляция (по средством emit) в процессе исполнения. Что ни есть ГУД по многим причинам (безопасность, стабильность, ресурсоемкость и утечки памяти). Кроме того каждый emit создает сборку, в которую помещает новый объект. При этом объем метаданных у каждой сборки в несколько раз выше самого кода, который был сгененрирован (кпд использования памяти очень низкое). А .NET не умеет выгружать сборки из домена приложения — явная утечка памяти.
Еще я не нашел кэширования инстанцированных «типов» контекстов (это беглый анализ и я могу ошибаться, просто не нашел) — значит при каждом создании контекста память будет утекать.
Для большинства задачь достаточно того что умеет делать дизайнер Visual Studio
Кроме того, есть гораздо более простой синтаксис вызова команд:
using(var context = new DataContext(«ConnectionString»))
return this.ExecuteQuery(«exec sp_getItems @query», «12</12>»);
…
class Item
{
public long Id { get; set; }
public string Name { get; set; }
public string Description { get; set; }
}
А что касается самой библиотеки BLToolkit — то она не предполагает наличия никакого дизайнера, а значит 90% всех задачь ее пользователь вынужден писать самостоятельно.
Еще важный момент — ключевое слово abstract перед каждым наследником класса ItemAccessor говорит о том что в библиотеке используется динамическая компиляция (по средством emit) в процессе исполнения. Что ни есть ГУД по многим причинам (безопасность, стабильность, ресурсоемкость и утечки памяти). Кроме того каждый emit создает сборку, в которую помещает новый объект. При этом объем метаданных у каждой сборки в несколько раз выше самого кода, который был сгененрирован (кпд использования памяти очень низкое). А .NET не умеет выгружать сборки из домена приложения — явная утечка памяти.
Еще я не нашел кэширования инстанцированных «типов» контекстов (это беглый анализ и я могу ошибаться, просто не нашел) — значит при каждом создании контекста память будет утекать.
В BLToolkit динамические классы можно сгенерировать заранее и потом просто загружать сгенерированнуюс сборку. Посмотрите утилиту BLTGen
П.С. Кеширование там есть :) плохо искали
Linq вцелом
Вот как раз таки самого LINQ'а в статье не было ни грамма.
уверенность в том что код будет работать именно так как нужно
Очень сложно напортачить в вызове хранимки, по-моему.
она не предполагает наличия никакого дизайнера, а значит 90% всех задачь ее пользователь вынужден писать самостоятельно
Дизайнер, по моему скромному, это исключительно для RADостного программирования (дизайнер форм — отдельная песня). К тому же, я еще не встречал ни одного дизайнера, который мог бы предоставить доступ ко всей функциональности underlying-продукта, обеспечивая при этом хоть сколько-нибудь достойное качество выхлопа.
Linq вцелом — имелось ввиду LinqToSql (контекст статьи)
Очень сложно напортачить в вызове хранимки — согласен, если использовать только базовый набор типов, действительно сложно.
RADостное программирование — это компромис между скоростью разработки и оптимизированностью кода приложения. Личный опыт показывает что не стоит принебрегать RADостной разработкой там, где требования к продукту это позволяют.
Очень сложно напортачить в вызове хранимки — согласен, если использовать только базовый набор типов, действительно сложно.
RADостное программирование — это компромис между скоростью разработки и оптимизированностью кода приложения. Личный опыт показывает что не стоит принебрегать RADостной разработкой там, где требования к продукту это позволяют.
Но вцелом библиотека интересная для изучения… спасибо за ссылку
Обидно только то, что Linq2Sql напрочь не умеет работать с новыми фичами SQL Server 2008, такими как например hierarchyid.
Sign up to leave a comment.
Практика использования LinqToSql: Использование Linq для автоматизации вызовов хранимых процедур.