MVC, LINQ with Repository Pattern

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.

In the event you are displaying the employee and the additional data, and want an update of all that data, using Entity Framework gives you an easy approach.

Create your own object that is comprised of your various components -- known as a composite object. So a way of doing this for example would be:

   public class CompositeEmployee:Employee
   {
        public ObservableCollection<students> StudentList{get;set;}
        public Department {get;set;}
        public HumanResourceInfo{get;set;}
   }
</students>

In your server side you take the composite in for UpdateEmployee(CompositeEmployee)
and it will break out the pieces and do the separate updates.

You do have one thing to struggle with and that is how to handle things of one of the updates fails. Rollback the update or keep running returning a list of exceptions/errors that occurred.