Hi,
It sounds to me like you're looking for a way to convert a logical data model into a physical model, in code. Most applications do
not benefit from an entirely one-to-one relationship between logical entities and physical entities. Instead, think about the
aggregation of multiple objects into a single object if it will always be used as such in code.
For instance, if you expect to use an instance of objectB every time you are using an instance of objectA then there may not be a
need for objectB (even if it exists in your logical data model). You can then combine the objects into one entity. The physical
model would appear as such in C# (fields should be properties, but I wanted to reduce the amount of code):
public class ObjectA
{
public int AID;
public string AName;
public int BID;
public string BName;
}
Your data access code must be aware of this aggregation and convert a single update into two separate updates: One to table objectA
and one to table objectB.
If objectB may be used separately from objectA then you could use two classes as in your second example:
public class ObjectA
{
public int ID;
public string Name;
public ObjectB B; // reference an instance of an object
}
public class ObjectB
{
public int ID;
public string Name;
}
If you don't want to allow null references in the B property of ObjectA then you can enforce this in a constructor:
public class ObjectA
{
...
public ObjectA(ObjectB b)
{
if (b == null)
throw new ArgumentNullException("b");
this.B = b;
}
}
Your data access code could then update table objectA and table objectB separately from each respective object, without having to
check for null ObjectB references.
The problem in your first example is that you aren't enforcing the dependency to an instance of ObjectB, except through the logical
model's B_id attribute. This is a problem in a physical model since there is no way of knowing where, and if at all, an instance of
ObjectB is located that has the referenced B_id value. In that case you'd have to have a globally-accessible (static) list of
ObjectB instances that you would maintain separately from your ObjectAs. It's just much easier, and makes more sense IMO, to
reference ObjectB directly, as in your second example.
What happens when i try to call a save method and the id hasnt been
set??
If you require ObjectA always to have a reference to an instance of an ObjectB, as in my third example, then your data access code
that creates and initializes the objects must meet that requirement. By using the constructor mechanism as I described you'll
enforce this constraint at runtime. If your data access code doesn't load the objects properly then your application will fail with
an ArgumentNullException.
The data access code that saves the objects' values to the database won't need to check for null ObjectB references since it has
been enforced that the ObjectA.B property will never contain a null reference.
If you require that ObjectA can have a null ObjectB reference then your data access code that saves the object's values must account
for this by checking if ObjectA.B is a null reference. In the case that ObjectA.B is null, your data access code should either
ignore the update to the objectB table, since there is nothing to update, throw an exception or notify the user through the UI that
they are missing data (the latter should probably be in combination with an exception so that the data access layer throws an
exception and somewhere back up the stack it is caught and handled, and the user is notified)
