Вопрос о доступе к данным с LINQ и хранимыми прокси (не спрашивая, что лучше!)

Question

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

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

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

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

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

   Любые потоки в моей логике в # 2?

Answer 1

LINQ сама по себе является довольно общим, так как есть LINQ к объектам, LINQ к XML, LINQ к SQL, LINQ к 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 ...