Creating Data access layer in ASP.NET 1.1

[Guest]

hello, how ru all
pls tell me how can i create DAL and how can i use it in my ASP.NET pages
thanks

 

[Guest]

asad,
I'd suggest that before you set out to write a DAL, download and play around
with the MS Data Access Application Block V2 here:

http://www.microsoft.com/downloads/...0A-9877-4A7B-88EC-0426B48DF275&displaylang=en

I have used this for most of my SQL Server data access for several years,
and it's saved me hundreds of mindless hours writing database access code.
Peter

 

[sloan]

The Application Block is a DataLayer "Helper".

You still need to write a DataLayer.

The DataLayer tier is the one which communicates with the DataStore (most
often a DataBase, but a DataStore can be any thing which stores data, a
database, a xml file, an excel file, a text file, even a USB device with
probes on it). But most times, the database is the DataStore.

Create a new Assembly.

MyApplication.Data

The role of the DataLayer is to interact with the DataStore.

My general rule of thumb is that the DataLayer returns:

DataSets (plain ole DataSets, or strongly typed ones)
IDataReaders
A single value (scalars)
Nothing (void or sub in C# / Vb.net)

A DataSet is where you get data from the database, and you put the whole
shooting match in memory.

An IDataReader is where you get a "fire hose" of the data, a forward only, 1
row at a time. This is faster than the DataSet, because of less overhead.

A single value (scalar) is when you return a value from the database.
(Like, you do "Select count(*) from dbo.Emp"....all you want is the count)

The returns nothing..... is when you run insert, update, or delete queries
on the database. You're usually sending Data INTO the database, and not
really wanting anything back.. You just want to know it worked.

...
If you follow these rules, you can have a datalayer object.

Then.... you business layer calls/uses the datalayer object.

Think of it like this:
the data layer is meant to abstract how you talk to the database. Say
today, you're using Sql Server. A month from now your boss says your
company's CEO played golf with the Oracle president. and your company is
switching to Oracle. ( A dumb reason, but a reason none-the-less).

Because you had the foresight to author a correct datalayer object, the only
code you need to change is INSIDE the datalayer.
Because you sent generic things like DataSet, IDataReader, Scalars and
nothing back to your business layer..... you can make the change to Oracle
fairly quickly.

You'll definately have to change the code inside your DataLayer object, but
that should be it. Your business layer doesn't change. The business layer
doesn't care ~how you populated the DataSet, IDataReader (etc etc), it only
cares that it WAS populated.
Whether the DataSet, IDataReader was populated by Sql Server, Oracle,
Access, Excel, a text file, an xml file becomes irrelevant to the business
layer.

I hope that helps.

Now, to make your life easier...writing your datalayer, there are "helpers".

http://msdn.microsoft.com/library/?url=/library/en-us/dnpag2/html/EntLib2.asp
(2.0)

http://www.microsoft.com/downloads/...09-660E-444E-945A-6B32AF1581B3&displaylang=en
(1.1)

The Enterprise Library does alot of the redundant database calls for you.
Its worth a $1,000,000 to learn how to use it.
It makes writing your DataLayer object much much easier.


Good luck!

...