Вопрос о доступе к данным с помощью LINQ и Stored Procs (НЕ спрашиваю, что лучше!)

Question

Во-первых, я НЕ пытаюсь стимулировать еще одну дискуссию о LINQ против хранимых процедур.

Предположим, что для этого вопроса (правильно или неправильно) я собираюсь использовать хранимые процедуры SQL-сервера и будуполучить доступ к этим хранимым процедурам через LINQ.Я использую хранимые процедуры (опять же, для правильных или неправильных), потому что я хочу обеспечить безопасность на уровне хранимых процедур по сравнению с базовыми таблицами и представлениями.Я использую LINQ (еще раз, правильно или неправильно), потому что я хочу его изучить.

1. Учитывая вышеизложенное, мои запросы LINQ должны быть относительно простыми инструкциями SELECT (очевидно, просто ссылающимися начтение данных в этом вопросе), а не запросы LINQ, которые содержат группировки или вычисления или вообще другие более сложные вещи.Это предположение основано на моем плане поместить эту логику в T-SQL.Другими словами, мои LINQ-запросы будут относительно «тупыми».Кроме того, учитывая мое желание обеспечить безопасность на уровне хранимых процедур и не разрешать доступ к базовым таблицам, я считаю, что этот подход соответствует этой цели.

   Есть ли какие-либо недостатки в моей логике в # 1?

2. Если бы я использовал LINQ непосредственно по отношению к базовым таблицам, я бы, очевидно, должен был обеспечить безопасность напрямуюна этих базовых таблицах.Это кажется очевидным, но я хотел подтвердить.

   Какие-либо потоки в моей логике в # 2?

Answer 1

LINQ сам по себе достаточно универсален, поскольку есть linq-to-objects, linq-to-xml, linq-to-sql, linq-to-EF и т. Д. Я думаю, вы, вероятно, будете следовать за Linq- функциональность to-Sql (в отличие, скажем, от Linq-to-EF). Делая так, чтобы все ваши наборы обеспечивались хранимой процедурой и опрашивали эти наборы в приложении с помощью Linq, я бы сказал, что вы научите себя весьма искаженному способу использования мощности Linq в целом и Linq-to-Sql в частности. Вы пропустите большую часть ноу-хау, которое поможет понять, как Linq-to-Sql генерирует SQL-запросы, отправленные на сервер, потому что вы сможете выполнять только самые простые «глупые» запросы, как вы говорите. Например. вы даже не сможете объединиться в Linq-to-Sql. И вы упустите возможность правильно понять возможности ORM в Linq-to-Sql, кеширование, которое входит в DataContexts, и поведение ActiveRecord, которое позволяет вставлять / обновлять / удалять элементы из наборов.

Хотя я не выступаю против того, чтобы делать то, что вы делаете (это очень правильный подход для совместного использования хранимых процедур и linq), я бы сказал, что это плохой подход к изучению Linq. Попытайтесь замочить ноги с помощью прямого подхода, такого как моделирование данных в Visual Studio с файловым подходом .dbml, отстаиваемого евангелистами Linq в 2008 году. Хотя я считаю, что этот подход несовершенен для развертывания крупных, жизнеспособных проектов, он хотя очень хорошо учить себя Linq и Linq-to-Sql в частности. Как только вы поймете, как все работает, вы сможете понять, как правильно использовать это с помощью хранимых процедур для разделения контроля доступа (подход, который всегда восхваляют евангелисты SQL Server) и как решать проблемы, не решаемые с помощью .dbml. подход к моделированию (в частности, проблема обновления схемы базы данных).

Некоторые могут сказать, что вам также следует следить за тем, что может предложить Entity Framework, но если вы находитесь в стадии обучения, я полностью рекомендую Linq-to-Sql. Он менее сложен, работает, нормален, хорошо поддерживается в наборе инструментов VS, и вам не нужно изучать Entity-SQL ...