Question

I started my website, like stackoverflow, with a little technical debt that I’m trying to pay off. Being a contract developer, I’ve been in many places and see many different methods of achieving this result, but the way I’m going is..

Presentation (web)

Business Layer (old fashioned entity classes and BL layer)

Data Layer (DA classes to SQL Server via Stored Proc)

My question primarily concerns the Business Layer. Right now I have an Entity namespace and a BusinessLogic namespace.

The BL has a reference to the DA and the Entity. The Entity has a reference to the DA (The DA is ‘unaware’ of the BL or Entity)

I really want all my churning of turning Data into Entities to occur within the BL — thus the Business Logic. However, I want the Entity to be able to access the BL if need be — and thus remove the Entity’s reference to the DL.

So…

Is is ‘wrong’ to have the BL and Entity objects within the same namespace so they can work together?

Essentially, I’m trying have an entity object like Employee (classic example, eh?) and have the Employee have a

public Hashtable[] SubordinateEmployees 

property that returns a Hashtable of other Employee objects that report to this employee. But I don’t want to load it until it’s needed. So for most employees the property would never get accessed, but when it does, it self-loads with a call to the BL, which calls the DA.

Does the question make sense?

If so, does my solution?

Thanks so much in advance!

Answer 1

The usual way to deal with the kind of situation your example represents is with facades. Instead of trying to get the subordinate employees from the Employee object, you use a call to the business logic to get it.

hashtable = BL.GetSubordinateEmployees(supervisor); 

That way you have a single point of access to the subordinates, and there is only one thing (the BL) accessing the data layer and creating Entities.