Какие плюсы и минусы есть в использовании linq to sql против создания моего собственного уровня данных?

Question

Я только начал играть с Linq to SQL на днях, и мне было любопытно, стоит ли использовать его в будущих проектах. Я знаю, что это сэкономит мне кучу времени на разработку. Я видел много подобных вопросов на эту тему, но у меня есть несколько более конкретных вопросов.

• Что-то не так с наследованием классов, сгенерированных в файле .dbml?

• Эффективны ли сгенерированные команды SQL? Когда я использовал SQL Server Profiler, я заметил, что при получении списка всех записей, использующих linqDataSource для привязки к gridView, я вижу два выполняемых запроса. Первый был

  SELECT COUNT(*) and then a SELECT TOP(PageSizeOfGrid).  
  

  Почему?

• Будет ли лучше использовать ObjectDataSource для получения всех записей из хранимой процедуры и их кэширования?

• Entity Framework? Не знаю много об этом, но я думаю, что он может быть слишком тяжелым для моих нужд. Большинство моих баз данных - это довольно простые 10-20 таблиц, которые могут иметь много-много взаимосвязей. Стоит ли искать?

Любые идеи по этому поводу приветствуются. Спасибо!

Answer 1

Не является прямым ответом на ваш вопрос. Но: я бы никогда не написал бы свою собственную библиотеку доступа к данным с нуля. Это отнимает много времени и является слишком общей проблемой, которую не стоит решать для одного приложения.

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

• NHibernate
• Линк к Sql
• Entity Framework
• довольно много других ORM

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

Answer 2

Что-то не так с наследование классов, сгенерированных в файл .dbml?

Нет, ничего страшного. И аналогично, вы можете сделать сгенерированные классы наследуемыми от ваших собственных базовых классов или реализовать другие интерфейсы, кроме готовых.

Являются ли сгенерированные команды SQL эффективный?

Да, но, как всегда, вам нужно следить за этим. Если вы напишите свои запросы linq так же, как и хорошие запросы SQL, сгенерированный sql будет очень эффективным. L2S довольно хорошо оптимизирует при некоторых сценариях, например он устраняет все, что может быть устранено на клиенте и т. д. Тем не менее, позволяет сделать его генерирующим плохой SQL так же, как можно писать неэффективные необработанные SQL-запросы вручную. Нажмите здесь для примера ...

Когда я использовал SQL Server Profiler I заметил, когда я получу список всех записи, использующие linqDataSource для связывания к gridView я бы увидел два запроса выполняется. Первый был ВЫБЕРИТЕ СЧЕТЧИК (*), а затем ВЫБЕРИТЕ Топ (PageSizeOfGrid). Почему?

Понятия не имею, никогда не использовал LinqDataSource. Я предпочитаю выполнять необработанные запросы linq, я не фанат автоматических элементов управления / объектов источника данных. Надеюсь, кто-то еще может пролить свет на это.

Буду ли я лучше использовать ObjectDataSource получает все записи из хранимой процедуры и кэширования их

То же, что и предыдущий ...:)

Entity Framework? Не знаю много об этом, но я думаю, что это может быть слишком тяжелый для моих нужд. Большинство из моих базы данных довольно просты 10 - 20 таблицы, которые могут иметь много ко многим отношения. Стоит ли искать в

Дождитесь следующей версии EF. Он будет выпущен как часть .net 4.0. Текущая версия EF не готова для прайм-тайма, и по какой-то странной причине Microsoft решила не исправлять базовые проблемы, а вместо этого посвятила все свое время и энергию работе над 4.0. Будет ли тот достойным конкурентом / заменой L2S, еще неизвестно. (Я пробовал только бета 1, и он страдает теми же проблемами, что и EFv1; в первую очередь это проблемы с плохо сгенерированными SQL-запросами ... ( ex 1 ex 2 ex 3 и т. Д.)

Answer 3

Если все в порядке, чтобы иметь возможность ориентироваться только на SQL Server, я бы начал использовать LINQ to SQL, так как это очень помогает создать прозрачный и основной уровень данных. Если производительность является проблемой, вы можете выборочно использовать прямой код SQL или хранимые процедуры для извлечения некоторых объектов.

Что касается LINQ to Entities, мне нужно было использовать его только один раз, в проекте, в котором мне пришлось использовать службы данных ADO.NET (необработанные классы, сгенерированные LINQ to SQL, не реализуют IUpdateable и поэтому доступны для чтения. только при использовании этой технологии), и я не нашел какого-либо убедительного преимущества по сравнению с LINQ to SQL (я не говорю, что нет таких преимуществ, только то, что я не нашел их для своего конкретного проекта, который просто имел несколько таблиц базы данных как у вас).