VB.net / C# dont reference sqlreader in client portion then where?

Question

Assume I have a form that has say 5 text boxes and I need to pull some data from a database then set those 5 text boxes with that data.

So assume I have 3 basic layers:

• the code behind for a default.aspx page

• a BLL class that contacts the DAL

• and a data access layer (DAL)

But I've heard and read that the default.aspx page should not know about sqldatareader, in fact you probably dont want to add the sqlclient namesspace to the default.aspx code behind page.

So I used to do something like this:

protected sub DisplayCustomerData()

Dim s as SqlDataReader
Dim b as BLL

b=new BLL();
s = b.GetCustomerData();

//then take s and simply set each text field
if s.read()
TextBox1.Value = s("MyField1")
end if
end sub

Then the BLL would simply call the DAL to call a stored procedure in SQL Server and do a CommandObject.ExecuteReader, get the results pass it back to BLL and BLL would then send it to the code behind page of default.aspx.

I can provide full source code if that doesn't make sense. My question is if its bad that default.aspx actually declares and knows about an SQL Data Reader then what is the better way to do this? What datatype should I be using to avoid having an sqldatareader in my interface code ?

Answer 1

You've introduced multiple layers, without actually separating concerns. By using SqlDataReader in your front end, it needs too much knowledge of how the data is retrieved.

Typically you'd have a Customer Business Object or Data Transfer Object that contains the retrieved data. Your DAL would returns objects of the Customer type, rather than a reference to a SqlDataReader.

protected sub DisplayCustomerData()

    Dim customer as Customer
    Dim b as BLL

    b=new BLL();
    customer = b.GetCustomerData();

    If Not customer is Nothing Then
        TextBox1.Value = customer.MyField
    End If
end sub

Update:

What you call the BLL in your example, wouldn't really do anything. There is just data access and presentation of that data. The DAL itself builds the Customer object.

The way you're using b, it really is a Data Access Object. It doesn't really have anything to do with business logic. Business logic would be something like determining the discount percentage this customer receives, based on past orders.

Answer 2

Layers are about encapsulation. The idea of a multi-tier architecture is to separate concerns into separate encapsulated layers, e.g.

Data Access Layer

Encapsulates all information about how data access is performed. Does not accept or return any types that indicate how data access is performed (i.e. it does not accept or return data readers, data sets, or anything like that). Its job is to persist and retrieve objects. You should ideally be able to swap out your data access layer with one that has the same contract but uses an entirely different persistence mechanism.

Business Logic Layer

Performs business logic functions, whatever they may be for your domain. Does not care about how it gets data, and does not know whether the caller is a web site, web service, windows forms application, etc. (i.e. it does not deal with any UI objects).

Presentation Layer(s)

Deals with presentation of stuff, whether that's in the form of an API or a web site or whatever. You should be able to have multiple parallel presentation layers that can use your business logic layer if you've written it in the right way. This layer does not call the data access layer.

---

Note that there is no particular requirement for this to be the actual layer structure you use, it's just a reasonably conventional one. We, for example, insert additional layers for things like cache management.