Лучше использовать linq2sql для генерации классов для хранимых процедур или для непосредственного вызова хранимых процедур?

Question

Я вижу тонны вопросов по LINQ to SQL против хранимых процедур. Мне более любопытно узнать о преимуществах их использования в тандеме, связанных с отображением объектов.

У меня определены бизнес-объекты, и у меня есть хранимые процедуры для всех моих транзакций CRUD.

Лучше ли поместить все сохраненные процессы в файл DBML и вызвать их оттуда, а затем сопоставить результаты с моими бизнес-объектами, или лучше просто использовать DataReader и отобразить его оттуда?

Это раздражает меня, потому что я хочу, чтобы мои объекты были такими, как я их определяю, вместо того, чтобы использовать объекты MyStoredProcResult, которые генерирует linq2sql, поэтому я чувствую, что я сопоставляю поля с тем же полем, что и с устройством чтения данных.

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

Answer 1

Отображение в LINQ2SQL имеет серьезное преимущество в том, что оно обеспечивает безопасность типов - вам не нужно беспокоиться о разборе результатов или добавлении параметров команды.Это все для вас.

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

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

Answer 2

Не прямой ответ на ваш вопрос, но если вы хотите, чтобы ваши объекты были результатом запроса, вы, вероятно, должны рассмотреть схемы кода вначале.Linq2SQL не поддерживает это, но Entity Framework и NHibernate делают.

Прямой ответ заключается в том, что DataReader, очевидно, будет иметь меньше накладных расходов, но в то же время будет иметь гораздо больше волшебных строк.Накладные расходы плохо с точки зрения производительности (в вашем случае не так уж и много).Волшебные строки плохи с точки зрения поддержки кода.Так что определенно это будет ваш личный выбор.

Answer 3

LINQ2SQL может предоставить ваши объекты, заполненные результатами запроса. Вам придется создавать дочерние объекты таким образом, чтобы поддерживать либо List (Of T), либо List в зависимости от вашего выбора языка.

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

var doSomething = from sList in myTableRef select sList;

вернет анонимный тип. Однако, если у вас также есть такой класс:

public class Company
{
  public integer ID;
  public string Company;
  public string PhoneNumber;
}

изменение вашего запроса на это будет заполнять объекты Компании при перемещении по данным:

List<Company> companies = (from sList in myTableRef select new Company 
                          { .ID = sList.id,
                            .Company = sList.company,
                            .PhoneNumber = sList.phonenumber }).ToList();

Мой синтаксис C # может быть не на 100% правильным, так как я в основном кодирую на VB, но он будет достаточно близок, чтобы доставить вас туда.