Question

The application that I help support has no real business objects to speak of, despite it being a sizable, ostensibly n-tiered project. What our team refers to as “business objects” are really nothing more than auto-generated wrappers around our database rows, and all the actual business logic is mixed in with the web UI code. For new functionality, I’d really like to see our team start working with/coding objects that truly represent the business entities’ data and behavior, and keep business logic out of the UI as much as possible. There’s some conflict, however, about how the relationships should be modeled.

To vastly oversimplify the domain for purposes here, say you have Persons and Tasks. Each Task has a Person assigned to it.

public class Person
{
    public int ID { get; set; }
    public string FirstName { get; set; }
    public string LastName { get; set; } 
}

How should Task be modeled?

public class Task
{
    public int ID { get; set; }
    public string Title { get; set; }
    public int AssignedPersonID { get; set; } 
}

OR

public class Task
{
    public int ID { get; set; }
    public string Title { get; set; }
    public Person AssignedPerson { get; set; } 
}

Those that spend more time coding the web UI want the earlier, in which Person is referenced by his ID. They argue that when, say, a different Person is assigned to a Task, it’s better to just change task.AssignedPersonID (the new ID being easily available from their dropdown list on the UI) and write to the database. To me this is no different from the approach we’re doing now; it still reflects a database row more than the actual business model. They argue that it’s more code and slower to have to take that PersonID, instantiate the corresponding Person instance, and then set task.AssignedPerson, when the end result — that the AssignedPersonID column in the Task table is updated — is exactly the same.

From a object-oriented perspective, what is the preferred approach here?

Answer 1

I’d prefer having an actual reference to the object instead of just the ID.

If you have just the ID, and you would frequently be using that to look up the Person to do stuff with it, you’re in bad shape because those frequent lookups will take time. If on the other hand, you have the Person object, and need the ID instead, it’s as simple as calling Person.ID.

There are some possible reasons for going with the ID route, and Wes hits on several of them that I wasn’t even thinking about (performance issues, in particular), and also the fact that it lines up with your database structure better, and (depending on how your code is currently structured) it may require fewer code changes to do this, but I don’t think either of those are that compelling of reasons to go with it.

So while it depends on the specifics, I think most OO programmers would prefer having the actual object reference.

By the way, the title uses the word “Parent” and “Child” which (you probably already know) have specific meanings in the context of inheritance in object-oriented programming. This doesn’t look like a parent-child relationship to me, but rather, a “this-uses-that” kind of relationship. Your question is perfectly valid, but the title/header might be a little misleading, and you might get better answers with slightly different terminology.