OOB design - class fields

Dell Simmons

I'm a hobbyist learning slowly about C# & OOD & N-Tier. I was looking at a couple of how-tos on the web today. Both had the business layer talking to the data layer like this example-

public class BusinessLayer
{

    public int Method1(string firstName, string lastName)
    {
        DataLayer dataLayer = new DataLayer();
        return dataLayer.DoSomething(firstName, lastName);
    }

    public int Method2(int personID, string firstName, string lastName, int age)
    {
        DataLayer dataLayer = new DataLayer();
        return dataLayer.DoSomethingElse(personID, firstName, lastName, age);
    }

}

I would have coded it like this -

public class BusinessLayer
{
private DataLayer dataLayer = new DataLayer();

    public int Method1(string firstName, string lastName)
    {  
        return dataLayer.DoSomething(firstName, lastName);
    }

    public int Method2(int personID, string firstName, string lastName, int age)
    {
        return dataLayer.DoSomethingElse(personID, firstName, lastName, age);
    }

}

Assuming my way is wrong, why is their way correct? Is it an encapsulation principle that I don't understand correctly or something else? Thanks.

ricmil42

I've seen it done the first way when the number of users of the system exceeds the number of database licenses. The DataLayer connects only for a short time to get the needed data. This way you can have 10 users on a database with 5 licenses. The DataLayer waits for an open connection then quickly connects/disconnects so the next query can be processed. Your way of connection will provide data more quickly but you need enough database licenses for all users.

Dell Simmons

Ah ha! That makes a lot of sense. Thank you.

Abhinav S

If you need the dataLayer to be around for the entire class, your way is right. Remember this object will be lying around for the duration of the existince of the BusinessLayer class - it will not be garbage collected. If you create it within a method, it will be garbage collected if you are running out of space. Personally, I would write this piece of code the way you have written it.

The funniest thing about this particular signature is that by the time you realise it doesn't say anything it's too late to stop reading it. My latest tip/trick Visit the Hindi forum here.

Keith Barrow

Good question (I've 5'd you) but personally, I think there are better solutions than both of the above. The business layer should be agnostic of the data layer as far as possible. The Data layer should have CRUD operations for the business objects, not the business layer calling the data layer. This is better separation of concerns IMO. If you are actually "just" interested in persisting models (as opposed to doing this as an exercise in itself) it is worth giving the Entity Framework a look, or NHibernate. They map object model to relational models whilst having minimal/little impact on the purity of the object model itself.

Sort of a cross between Lawrence of Arabia and Dilbert.[^]

Nish Nishant

The former approach is also used when it's desirable to keep the business object alive while at the same time releasing the data-layer object for garbage collection.

Regards, Nish

My technology blog: voidnish.wordpress.com Code Project Forums : New Posts Monitor This application monitors for new posts in the Code Project forums.

Paul Michalik

Nor of the two is fundamentally wrong. As other posters have pointed out it depends on the required life-time of the DataLayer object. I would however recommend to decouple the dependency between the layers via interfaces:

public interface IDataLayer {
void DoSomething(string firstName, string lastName);
}

public interface IDataLayerFactory {
IDataLayer Generate();
}

Then, your first and second alternatives become:

public class BusinessLayer {
private IDataLayerFactory dataLayerFactory;

protected BusinessLayer() {
dataLayerFactory = null;
}

public BusinesLayer(IDataLayerFactory pDataLayerFactory) {
dataLayerFactory = pDataLayerFactory;
}

public int Method1(string firstName, string lastName) {
return dataLayerFactor.Generate().DoSomething(firstName, lastName);
}

}

public class BusinessLayer {
private IDataLayer dataLayer;

protected BusinessLayer() {
dataLayer = null;
}

public BusinesLayer(IDataLayer pDataLayer) {
dataLayer = pDataLayer;
}

public int Method1(string firstName, string lastName) {
return dataLayer.DoSomething(firstName, lastName);
}

}

Of course there has to be an implementation:

class ASpecificDataLayer : IDataLayer {
public void DoSomething(string firstName, string lastName) {
// implementation goes here
}
};

class ASpecificDataLayerFactory : IDataLayerFactory {
public IDataLayer Generate() {
return new ASpecificDataLayer();
}
};

The fundamental difference is that your buiness layer does not depend on a specific implementation of a data layer, it only depends on the interface which can be implemented in various ways. This idiom is fundamental in OOD and is called dependency inversion. There is a lot of support for this pattern at framework level in form of so called dependency containers or service locators. Please google on the boldified termini for further information. Cheers, Paul