im пытается понять LINQ, поскольку я понимаю, что LINQ будет вашим DAL для вашего db, который, в свою очередь, автоматически создает для вас класс, который отображает вашу структуру db для вас, а затем вы можете выполнять запросы с использованием этого класса.
Я правильно в своем предположении?? пожалуйста, просветите меня
"Linq" не является технологией ORM, это просто способ писать запросы типа операторов внутри .Net-языков. Вы не сказали, используете ли вы Ling для SQL или Linq для Entities, которые являются технологиями ORM, которые работают с Linq для сопоставления вашей схемы данных с таблицами.
Linq to SQL предоставит вам прямое сопоставление каждой таблицы с классом и обработает большую часть отмены, чтобы это сделать. Ваши запросы могут возвращать эти типы или использовать выражение Linq, вы можете "проецировать" эти типы на другие типы, которые вы создали сами.
Если вам нужна большая гибкость, Entity Framework позволит вам сопоставить одну таблицу с несколькими сущностями, несколькими таблицами с одним объектом и т.д. Для этого вам нужно сделать гораздо больше работы самостоятельно, поскольку у вас есть для изменения отображения вручную во многих случаях. Подобно Linq to SQL, запросы могут возвращать либо эти сгенерированные типы, либо определять их собственные типы в запросе.
По умолчанию конструктор Linq to SQL создаст класс для каждой таблицы в вашей базе данных. Созданный объект контекста базы данных будет иметь определение для каждой таблицы в вашей базе данных. Вы можете выполнять запросы Linq для этих определений таблиц и сохранять результаты в сгенерированных классах, у вас есть ваши запросы, генерирующие анонимные типы. Это зависит от вас.
Основываясь на названии вашего вопроса, я бы сказал нет. Могут быть случаи, когда у вас есть таблицы, которые вам не нужно сопоставлять с Linq2SQL. Один непосредственный пример, который приходит на ум, заключается в том, что если вы используете API-интерфейс членства ASP.NET, вам не нужно будет перетаскивать эти таблицы /sprocs/functions в конструктор, поскольку эти данные отображаются API.
Если вы используете конструктор (DBML файл), вы можете выбрать, какие объекты db должны вносить в ваше решение. Это способ, которым я это сделал, только привлечение тех объектов db, к которым я действительно нуждаюсь. В качестве другого примера я работал в одном магазине, который был сильно связан с идеей доступа всех db через хранимые процедуры. Поэтому в этом случае я работал со многими результатами [StoredProcedureName], которые я, в свою очередь, сопоставлял с другими объектами, а не с самими фактическими таблицами, которые даже не были определены в решении.