With LINQ the code side of things should pretty much work just like objects (I'm assuming by Tables you mean DB tables, I'm a little unclear about your question. You shouldn't think of
Employee
as something from a table as much as an obect that happens to be stored in a table.To set this up, you need to add a
Department
type. The
Employee
should have a
Department[s]
property (i.e. one, or more, related Department) and vice versa. You can then access the properties as normal objects and write to the backing store through LINQ.
If you are using the Entity Framework, if you add the Department Table as a new type in your entity model, it should add the properties for you with the correct cardinality, as long as you have normalised your Database properly. With LINQ to SQL you can look
here[
^] about how to define the relationship.