Что не так с Linq to SQL?

Что ж, я разработал несколько приложений, использующих LINQ to SQL. Одна из основных проблем, с которыми я столкнулся, - это необходимость многоуровневого приложения. В LINQ to SQL классы сущностей очень тесно связаны с кодом доступа к данным. Кроме того, есть некоторые проблемы с DataContext, что означает, что вы можете использовать объект DataContext для извлечения элемента, но вы не можете передать элемент (объект) в другой DataContext (по крайней мере, не легко).

LINQ to SQL будет полезен, если вы не заботитесь о правильном распределении уровней своего приложения, а также если все, что вам нужно, - это быстро создать приложение, также известное как RAPID Application Development.

Он не очень адаптируется к изменениям в схеме базы данных. Вам необходимо перестроить слой dbml и восстановить контексты данных.

Как и любой ORM (я не вникаю в дискуссию о том, является ли это ORM или нет), вы должны знать, какой SQL генерируется и как это повлияет на ваши вызовы.

Пластины не комплектуются партиями, поэтому их производительность может быть высокой.

Он отменяется в пользу Entity Framework.

Несмотря на то, что он использует модель поставщика, которая позволяет создавать поставщиков для других платформ СУБД, поддерживается только SQL Server.

[РЕДАКТИРОВАТЬ @ AugustLights - По моему опыту:] Ленивая загрузка май требует небольшого взлома, чтобы заставить работать.

При этом я думаю, что это очень удобно, если использовать правильно

Большое преимущество LINQ-to-SQL заключается в том, что якобы он может создавать запросы данных прямо в коде программной части на основе строго типизированных запрашиваемых / перечислимых объектов данных из вашего dbml (который играет роль очень ограниченного DAL) . Таким образом, как уже упоминалось, следствием этого является то, что это побуждает вас играть за пределами строго определенных и разделенных слоев или уровней вашего приложения. Чтобы противостоять этому пункту, это должно означать, что вы должны иметь возможность исключить большую часть или всю любую бизнес-логику, которую вы записывали в хранимые процедуры в базе данных, поэтому, по крайней мере, вам нужно только перейти к коду, который имеет дело с данными для изменить бизнес-правила, не влияющие на схему ... Однако это немного нарушается, когда вы понимаете, насколько сложным может быть написание запроса с внешним соединением с агрегатами с группировкой, по крайней мере, когда вы впервые приближаетесь к нему. Так что у вас возникнет соблазн написать sprocs в SQL, который, как вы знаете, настолько прост и хорош для выполнения этих задач, вместо того, чтобы тратить дополнительное время на попытки выяснить синтаксис LINQ, чтобы сделать то же самое, когда он просто собирается его преобразовать. к уродливому коду SQL в любом случае ...
Как уже было сказано, я действительно люблю LINQ, и мое уважение к нему значительно возросло, когда я начал игнорировать это мнение о том, что «синтаксис запроса легче читать», которое я наблюдал и переключился на синтаксис метода. Никогда не оглядывался.

При модульном тестировании сложно имитировать из-за отсутствия интерфейса в классе System.Data.Linq.DataContext. Вот возможный подход: Мокинг LINQ to SQL DataContext.

потому что вы не используете 3.5 ... это правильный ответ?!?!?

Для проекта, которому необходимо использовать базы данных, отличные от SQL Server:

1) Вы заблокированы для использования SQL Server

Для проекта со сложными отношениями сущностей и / или отношениями, которые постепенно меняются с течением времени:

2) Вы привязаны к однозначному сопоставлению таблиц с классами.

Для проекта, который должен использовать версии .NET 1.x

3) Не будет работать с .NET 1.x

Этот вопрос задавали один раз перед сюда. Но, по сути, LINQ to SQL генерирует неоптимальные планы выполнения в вашей базе данных. Для каждой разной длины параметра, который вы ищете, это приведет к созданию другого плана выполнения. В конечном итоге это приведет к засорению памяти в вашей базе данных, которая используется для кэширования планов выполнения, и вы начнете истекать старые запросы, которые необходимо будет перекомпилировать, когда они появятся снова.

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

• Невозможно смешивать ленивую загрузку / нетерпеливую загрузку для контекста данных.
• Истинное настойчивое невежество очень сложно.
• Возможности отображения ограничены. Например, нет отношений «многие ко многим».
• Повторная синхронизация сопоставления с изменениями схемы болезненна.

Несмотря на все вышесказанное, я считаю, что linq-to-sql - отличный выбор для многих проектов.

Единственное, что я бы назвал техническим «препятствием», - это если вы хотите использовать другие СУБД, кроме SQL Server. (хотя это можно обойти - см. блог Мэтта Уоррена @ http://blogs.msdn.com/mattwar/)

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

Нетехнический [потенциальный] препятствие - это риск того, что MSFT откажется от него в пользу EF ... Подробнее об этом здесь: http://oakleafblog.blogspot.com/2008/05/is-adonet-team-abandoning-linq-to-sql.html

Хотя (на мой взгляд) текущее состояние EF является достаточным основанием для продолжения работы над L2S. Так что будем надеяться, что они это сделают ...

Это похоже, не имеет - любая поддержка значений по умолчанию для столбцов БД.

Настоящая ORM должна отделять дизайн ваших бизнес-объектов от вашей среды сохранения. Таким образом, вы можете провести рефакторинг любого из них по отдельности, и вам нужно будет только поддерживать сопоставление между ними. Это сокращает объем кода логики приложения, который необходимо поддерживать при изменении базы данных.

Чтобы реализовать такой подход, не зависящий от персистентности, с Linq-to-SQL, вам нужно будет использовать его сгенерированные классы в DTO и поддерживать логику сопоставления между вашими DTO и вашими объектами.

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