Проблемы с концепцией Linq to sql в точечной сети

Question

Допустим, если бы я использовал концепцию Linq to Sql для взаимодействия с базой данных на языке C #, то с какими проблемами я могу столкнуться?средства с точки зрения архитектуры, производительности, безопасности типов, ориентации объектов и т. д.!

Answer 1

У нас было несколько проблем, в основном от открытия возможности конструирования запросов до программистов, которые не понимают, как работают базы данных. Вот несколько запахов:

//bad scaling
//Query in a loop - causes n roundtrips
//  when c roundtrips could have been performed.
List<OrderDetail> od = new List<OrderDetail>();
foreach(Customer cust in customers)
{
  foreach(Order o in cust.Orders)
  {
    od.AddRange(dc.OrderDetails.Where(x => x.OrderId = o.OrderId));
  }
}

//no seperation of
//  operations intended for execution in the database
//  from operations intended to be executed locally
var query =
  from c in dc.Customers
  where c.City.StartsWith(textBox1.Text)
  where DateTime.Parse(textBox2.Text) <= c.SignUpDate
  from o in c.Orders
  where o.OrderCode == Enum.Parse(OrderCodes.Complete)
  select o;

//not understanding when results are pulled into memory
//  causing a full table load
List<Item> result = dc.Items.ToList().Skip(100).Take(20).ToList();

Другая проблема заключается в том, что еще один уровень отделения от табличных структур означает, что индексы еще проще игнорировать (хотя это проблема с любым ORM).

Answer 2

В основном Linq to SQL генерирует класс для каждой таблицы в вашей базе данных, в комплекте со свойствами отношений и всем, так что у вас не будет проблем с безопасностью типов. Использование партиалов C # позволяет добавлять функциональность к этим объектам, не возиться с автоматически генерируемым кодом Linq to SQL. Работает довольно хорошо.

Поскольку таблицы отображаются непосредственно на классы и объекты, вам придется либо принять, что уровень вашего домена отражает структуру базы данных напрямую, либо вам придется создавать некоторую форму уровня абстракции над Linq to SQL. Прямое зеркалирование таблиц может быть особенно проблематичным с отношениями «многие ко многим», которые напрямую не поддерживаются - вместо Orders.Products вы получаете Order.OrderDetails.SelectMany(od => od.Product).

В отличие от большинства других ORM Linq to SQL не просто распределяет объекты из базы данных и позволяет хранить или обновлять объекты, передавая их обратно в ORM. Вместо этого Linq to SQL отслеживает состояние объектов, загруженных из базы данных, и позволяет изменить сохраненное состояние. Это трудно объяснить и странно понять - я рекомендую вам прочитать некоторые посты Рика Стралса на эту тему.

В отношении производительности Linq-to-SQL работает довольно хорошо. В бенчмаркинговых тестах он показывает скорость около 90-95% от того, что обеспечивал бы нативный читатель SQL, и, по моему опыту, использование в реальном мире также довольно быстро. Как и все ORM, Linq to SQL подвержен проблеме выбора N + 1, но он предоставляет хорошие способы для определения отложенной / активной загрузки в зависимости от контекста.

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

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