views:

298

answers:

4

Should a business object contain a reference to other objects (as in the id field references another database record) or should it have an instance of the actual objects.

For example:

public class Company
{
    public int Id { get; set; }
    public CompanyStatus Status { get; set; }
}

or

public class Company
{
    public int Id { get; set; }
    public int Status { get; set; }
}
A: 

If you're talking about C#, then aggregating an object means you're storing a reference to it.

GregC
A: 

It depends on the data. Some data should be stored as a copy of the original object, some should be a reference.

Ludvig A Norin
+9  A: 

From my understanding, it should contain references to interfaces, not concrete classes.

public class Company
{
    public int Id { get; set; }
    public ICompanyStatus Status { get; set; }
}

Assuming that the concrete implementation of CompanyStatus in your example was a class and not an enum.

Rake36
I've been very happy with this approach in the last few years. Perhaps it has something to do with the fact that it allows me to inject dependencies (http://en.wikipedia.org/wiki/Dependency_injection) at run-time.
FOR
@Rake36: Why references to interfaces, and not to concrete classes?
John Saunders
For some cases, its preferable. It allows for swapping implementations, and helps with certain ORM technologies. It really puts more emphasis on the Contract for the business object.
Nader Shirazie
@John Saunders: Like nader is saying, and FOR yesterday as well - using Interfaces makes your code so much more flexible. I'm not a heavily experienced OO developer, but in forcing myself to create Interfaces before I create any concrete implementations, my code just flows together so much better. When I want to add a different implementation (especially when using a factory), I don't have to do much except create the new concrete class. The Business layer doesn't know the difference. You can accomplish this with inheritance heirarchies too, but Interfaces just seem to work better.
Rake36
If the class for example "Car" is holding a reference to a class/interface "Engine" shouldn't the class "Car" also contain the foreign key in a private field (engineId)? I ask this because - imagine Engine instance would be cached and Engine would be removed from the cache while Car is not, shouldn't a Car instance be able to reload its Engine? This could be done via lazy loading in the property "Engine" in Car by checking private reference "engine" field (case!) for null and (re-)create it by using the private engineId int field?!?What do you/anyone think about this?
toebens
+3  A: 

When creating Business Layer objects in an OO fashion, you should be using objects directly.

In your example, does int Status refers to the Id of a CompanyStatus object stored somewhere? In that case, it really feels like that's more of a data layer concern. It is usually best to avoid mixing your data layer with your business layer.

Nader Shirazie
So I'm correct in thinking that the DAL should have transalted CompanyId from the database into a `CompanyStatus` or indeed an `ICompanyStatus`, is this correct?
Anthony
Yup, exactly. And when you break it up that way, it gives you a bit more flexibility to change your DAL and business layers independently.
Nader Shirazie