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