Put it or not? Modeling classes from DataBase tables.-

Question

Guys I have another "best practice question"

For example I have this tables on my Sql Server:

--------------
Table: Client
--------------
(PK) clientID      long,
     clientName    varchar(50)


---------------
Table: Training
---------------
(PK)  trainingID   long,
(FK)  clientID     long,
      trainingName varchar(50)

Now Im using LINQ2SQL to map those tables.- But if now I want to create a business layer what Im doing is creating plain objects modelling those tables.- For example:

public class Client
{
   public long clientID {get; set;
   public string clientName {get; set;}
}

public class Training
{
   public long trainingID {get; set;}
   // And here goes my question!!
   public long clientID {get; set;}  // <--- Should this be here
   public string trainingNane {get; set;}
}

or should I remove it from there and modify my Client class to this:

public class Client
{
   public long clientID {get; set;
   public string clientName {get; set;}
   public List<Training> myTrainings {get; set;} //Clients have Trainings!
}

I mean should I create the classes as the DB is or should I use the common sense and figure that a client has many trainings (I will then create a method to find his courses) a method like this (could be on a ClientHelper class):

public List<Training> findMyTranings(long clientID)
{
   // Find the Trainings for that particular client
}

I hope you understand this stupid question, is about how to model the classes.-

Thanks in advanced!!

Answer 1

You want the latter - explicit relationships between objects, so that your business logic can work in terms of the objects (myClient.Trainings) instead of the DB schema (the set of Trainings with the clientid=x). That's the basis of Object-Relational Mapping, whether you use a special tool to handle that or not (I'd recommend using an ORM tool though). Make your access code smart so that your business logic doesn't have to be.

Answer 2

This is how I would expect it to be:

public class Client 
{ 
   public long ClientID {get; set; 
   public string ClientName {get; set;} 
   public IList<Training> Trainings {get; set;}
} 

public class Training 
{ 
   public long TrainingID {get; set;} 
   public Client Client {get; set;}
   public string TrainingNane {get; set;} 
} 

It's something of a superset of what you proposed, plus exposing Client as an object of training instead of as a long of the ClientID.

It seems that my proposal would exactly match (but cleaner POCO objects obviously) what LinqToSql generates, but I may not be remembering correctly.