CODEWITHSUNDEEP
oopclassdatabase-designdomain-driven-designentity-relationship
devanalyst
devanalyst

Reputation: 1478

Transition from ER way to OOP way

Coming from a traditional E-R diagram Database centric approach to designing applications, implementing classes using OO approach is causing confusions like shown in examples below

1) Implementing classes for a Many to Many relation.

Suppose you have two entities, Professor and College with following relations (I do not know how to draw in SO otherwise I would have illustrated the examples with diagrams):

Doing this the ER way, we would have tables like this

CollegeTable (CollegeId, CollegeName)
ProfessorTable (ProfessorId, ProfessorName))
LecturerTable (LecturerId, CollegeId, ProfessorId, Timings))

So the many to many relation is a table containing primary keys of both the entities and other relation specific data. If I had to create classes to represent rows of my table they would be like

class CollegeData
{
    string CollegeId;
    string CollegeName;
}

class ProfessorData
{
    string ProfessorId;
    string ProfessorName;
}

class LecturerData
{
    string CollegeId;
    string ProfessorId;
    DateTime Timings;
}

But doing the same in OOP and mapping entities to class we would have as follows

class College
{
    string CollegeId;
    string CollegeName;
}

class Professor
{
    string ProfessorId;
    string ProfessorName;
}

class Lecturer
{
    College aCollege;
    Professor aProfessor;
    DateTime Timings;
}

So now doing proper OO way is introducing more load on the system since now we are creating full blown class objects in the many-to-many class instead of only having the ID fields. Consider this implication when we have say a Lecturer add/edit page where we can edit the Timings or change the Professor. We don't need full blown Professor or College objects (since they will have their own master pages for add/edit), only their IDs.

2) Implementing classes for a One to One relation.

Extending above example, suppose we have have a Dean Entity with following constraint(for simplicity assume Dean is not a Professor)

Again the ER way we will have

class DeanData
{
    string DeanId;
    int DeanExp;
}

class CollegeData
{
    string CollegeId;
    string CollegeName;
    string DeanId;
}

, while doing it the OOP way

class Dean
{
    string DeanId;
    int DeanExp;    
}

class College
{
    string CollegeId;
    string CollegeName;
    Dean aDean; 
}

Also are the issues of mapping OO objects with their table structure representation in a relational database when saving or loading the data. Is there any way I could have done above in proper OO way but without having "redundancy"? Or is this a penalty to be paid for doing things the OO way ?

Upvotes: 0

Views: 204

Answers (2)

David Masters
David Masters

Reputation: 8295

If you're aiming to design your model based on DDD principles, then you don't want bi-directional associations in your model.

Udi Dahan wrote a good blog post regarding this very subject that I'd recommend you read:

DDD & Many to Many Object Relational Mapping

Upvotes: 1

Joel Brown
Joel Brown

Reputation: 14408

The problem, as you perceive it, is actually a little worse than you portray it, because the "proper OO way" as you call it should actually have back references at the one ends of the one-to-many relationships.

For example, your College-Lecturer-Professor model should look more like this:

class College 
{ 
    string CollegeId; 
    string CollegeName; 
    List<Lecturer> aLecturers;  // <=NOTE THIS
} 

class Professor 
{ 
    string ProfessorId; 
    string ProfessorName;
    List<Lecturer> aLecturers;  // <=NOTE THIS
} 

class Lecturer 
{ 
    College aCollege; 
    Professor aProfessor; 
    DateTime Timings; 
}

You are right when you observe that this creates overhead insofar as there are full-blown objects where your database contains only integer foreign key values.

The important difference is that you shouldn't have all of the data that is stored in your DBMS loaded into your object hierarchy at the same time.

From a coding standpoint, a lot of people like to use an ORM framework to automate the creation of the objects. ORMs can take out a lot of the grunt work of building up objects based on a properly designed relational database.

Upvotes: 2

Related Questions