do I need a class for every table for my db ?

Question

Hi, im trying to grasp LINQ as I understand it LINQ will be your DAL to your db which in turn creates for you automatically a class that maps out your db structure for you and then you can perform queries using that class ..

• im trying to do a function that would return the result of my LINQ queries ..
  • all the examples i have been reading seems to point that if I want my queries to be a defined type I have to create a specific class for it and used it as List ..

am I correct in my assumption ?? please do enlighten me

Answer 1

By default, the Linq to SQL designer will create a class for each table in your database. The database context object that is created will have a definition for each table in your database. You can execute Linq queries against those table definitions and store the results in the generated classes, you have your queries generate anonymous types. It's up to you.

Answer 2

"Linq" is not an ORM technology, it is simply a way to write query like statements inside of .Net languages. You have not said whether you are using Ling to SQL or Linq to Entities, which are both ORM technolgies that work with Linq to map your data schema to tables.

Linq to SQL will provide you with a straight mapping of every table to a class, and will handle most of the lifting to get this done. Your queries can return these types, or using your Linq expression you can "project" these types to other types that you have made yourself.

If you need more flexibility, Entity Framework will allow you to map a single table to multiple entities, multiple tables to a single entity, etc. To do this you have to do a lot more work on your own, since you have to modify the mapping by hand in many cases. Similar to Linq to SQL, queries can return either these generated types or specify their own types in query.

Answer 3

Based on the title of your question, i would say no. There could be instances that you have tables that you don't need to map to Linq2SQL. One immediate example that comes to mind, is if you were using the ASP.NET Membership API, you wouldn't need to drag those tables/sprocs/functions into the designer since that data is exposed by the API.

If you are using the designer(DBML file), you can pick and choose which db objects to bring into your solution. This is the way that I have done it, only bringing in those db objects that I actually need access to. As another example, I worked at a shop once that were strongly wed to the idea of all db access being done via stored procedures. So in that case, I worked with a lot of [StoredProcedureName]Results which I in turn mapped to other objects, never the actual tables themselves, which werent even defined in the solution.