Data Transfer between layers? Best Practice?

[Tokhra]

Hey all,

Im writing a web app which has the following layers:

ASP.NET Web Application, "Project", (Presentation Layer)
.Net Class Library, "Project.Business" (Business Layer)
.Net Class Library, "Project.Data", (Data Layer)

Im just wondering how I should communicate data between the Data and Business layers?

The first thing to come to mind is for the data layer to populate the business entity directly. e.g. (From a business entity)

public void Customer(int customerID)
{
CustomerData data = new CustomerData();
data.SelectCustomer(ref this, customerID);
}

So the CustomerData object would execute the db transaction and set the properties on the Customer object, which is passed by ref.

However..I cannot do this, as it requires that the Data assembly references the Business, and vice versa. .Net won't allow this saying its a round dependancy..

So what am I to do? Use DataSets? If I just want to return one customer's data, do I return a whole dataset? e.g. (From Customer business entity)

public void Customer(int customerID)
{
CustomerData data = new CustomerData();

ds = data.SelectCustomer(customerID);

this.CustomerName = (string) ds.Tables[0].Rows[0]["CustomerName"];
}

Seems kind of messy..?

Obviously I want to take into mind future extensibility, code management etc. What is the best practice for this?

Thanks,
Matt.

 

[weevilofdoom]

Well, this seems like a good use for a standard '3-tier' architecture to me. How you do this... you got your presentation layer, which shows data from your business objects, that's cool. You have your data layer, which gets/stores data to a database, this can be called our persistence layer.
What I'm proposing is putting a layer in between this, called the 'controller' layer. You facilitate business objects into these controllers. These controllers then can be passed to persistence objects, which write/read from your database.

At any rate, it's setup like this:

Presentation Layer -> Business Object -> Controller -> Persistence( db )

now code wise, I'll let you do that, but it's not too complex.

The weevil of doooooooooom
-The eagle may soar, but the weasel never gets sucked up by a jet engine (Anonymous)

 

[dragonwell]

To add to/reiterate weevil's sound advice - have a layer of Persistence classes, whose job is to manage the creating and saving of business objects for the presentation layer. The Persistence layer uses methods of the Data Layer to do it's dirty work, and supplies the objects to the Presentation layer without Presentation knowing anytihng about how th Data layer works. Plus, the business objects don't know how the Data Layer goes about persisting them. So you have:

Presentation Layer
-references Busines Objects
-references Persistence Layer

Persistence Layer
-references Business Objects
-references Data Layer

Business Objects Layer
- (no references to other layers)

Data Layer
- (no references to other layers)

The Data layer can be somethign you build for this application or a generic OR/Mapper.

The good thing about this design is that the DAL can be totally replaced with an completely different implementation and only the Persistence layer needs to get modified.

There is a lot more to this subject. just a quick overview of how I've got it to work. Actually this is an ideal... I usually have to resort to the business objects knowing a little about how the Data Layer works, to get lazy-loading to work.



Greetings,
Dragonwell

 

[Tokhra]

Thankyou for your posts Weevilofdoom and Dragonwell.

This architecture sounds good, im not quite grasping the concept yet though..any chance of a brief example? or any links?

Thanks,
Matt

 

[chiph]

The patterns & practices group at Microsoft have a number of good documents. Here's one that will help you out:

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnbda/html/BOAGag.asp

Chip H.


____________________________________________________________________
If you want to get the best response to a question, please read FAQ222-2244 first