Logical Tiers and DataReaders 1

[VBRookie]

Ok let me explain what I'm doing (or trying to do).
I'm not a system architect so please forgive me if I have the concepts or terminology wrong.

I have an n-tier app. It consists of the presentation layer, the business logic layer, the data access layer, and the database.

In the database I'm using stored procedures. The database physically sits on a different server from everything else.

I have a different assembly (the data access layer) that handles all calls to the db.

The code behind files for the aspx pages contain calls to methods within the data access layer to retrieve data for display, etc.

Now ... I'm passing data from the DAL in a datareader to the code behind files. Is this the best thing to do? I understand that its better to use a dataset when passing data between tiers because it handles marshaling better. Is that a factor when its just logical tiers

Also with inter-tier communication the whole chatty / chunky call deal doesn't really apply does it? That only becomes an issue when passing data between physical tiers?

Am I correct or wacko?
Please advise.

Thanks in advance,
- VB Rookie

 

[dragonwell]

So where is your business logic layer? Typically, the BLL accesses the DAL, not your presentation layer. Then the presentation layer only accesses the BLL.

So in that case, your BLL should only be returning objects or datasets to the presentation layer. You can use DataReaders, but keep them internal in the DAL.

Is that making sense?

 

[VBRookie]

I guess my BLL would be my code behind files ... because they are where I access the DAL.

The datareaders are in the DAL and are passed up to the BLL ...

 

[dragonwell]

ok, then. (Normally the code behind files are considered part of the presentation layer).

Now, I don't like using DataReaders across layers but that's just me. Manily because they need to be closed and I think whoever opened it should have to close it. Why not create a collection of objects (an IList) and have your DAL give that to the code-behind files?

 

[VBRookie]

Oh ... well is it bad design to use the code behind files as the BLL? If so would I need to create another assembly and use it as the BLL.

I'll have to research how to do the IList option but in the meantime are you saying that a Dataset is better? I thought maybe a datareader would be okay since the assemblies will sit on the same server. I use CommandBehavior.Close to make sure that the datareader and connection is closed in the code-behind file. But I understand what you're saying about the opener being the closer ...

- VB Roookie

 

[dragonwell]

is it bad design to use the code behind files as the BLL? If so would I need to create another assembly and use it as the BLL.

Not necessarily, althoug by putting the business logic into it's own library you could swap out the presntation layer with another type of user-interface easily (like a Web Service or Windows Form app) instead of ASP.NET. BUT, if that's not a concern, I don't see any reason for not putting business logic into the code behind.

Keep it as simple as possible.

 

[VBRookie]

Ok ...
Thanks dragonwell ...

- VB Rookie