Data Access Layer

[Guest]

I am writing a fairly large database application for the first time, and am finding it difficult to decide on how to create the data access layer. I have tried reading as much as I can find about them on MSDN, but have found conflicting views, and am now really quite confused.

For example, I am using typed datasets to store my data in. I have created a data access layer class, that basically has a set of procedures that accept a dataset, and fill it with some sort of data. These functions are basically static and stateless.

Should the data access layer be stateful?

Should I instantiate a data access layer in my main() method at the start of my application that basically fills my dataset when I first load my app, and then just pass a reference to the data layer into my various forms?

I am finding it hard to know how to split up my database tables into datasets - just for the part I am working on now, I have about 20 tables, all of which are accessed from a single form. Should these just be in a single dataset? Or should I split them into smaller subgroups. The problem I see with this is that any relations between them will no longer exist! Also, if I have other forms that want to use just one or two of these 20 tables, should I create a separate dataset for them, or just use the reference to the data access layer and return the relevant tables?

Sorry about the length of this post, but any help with any of the issues here would be greatfully received. Any links to good reference material would be useful too.

Pete

 

[Patrick Blackman]

look for "Microsoft Application Blocks for .net" on msdn

I am writing a fairly large database application for the first time, and

am finding it difficult to decide on how to create the data access layer. I
have tried reading as much as I can find about them on MSDN, but have found
conflicting views, and am now really quite confused.

For example, I am using typed datasets to store my data in. I have created

a data access layer class, that basically has a set of procedures that
accept a dataset, and fill it with some sort of data. These functions are
basically static and stateless.

Should the data access layer be stateful?

Should I instantiate a data access layer in my main() method at the start

of my application that basically fills my dataset when I first load my app,
and then just pass a reference to the data layer into my various forms?

I am finding it hard to know how to split up my database tables into

datasets - just for the part I am working on now, I have about 20 tables,
all of which are accessed from a single form. Should these just be in a
single dataset? Or should I split them into smaller subgroups. The problem I
see with this is that any relations between them will no longer exist! Also,
if I have other forms that want to use just one or two of these 20 tables,
should I create a separate dataset for them, or just use the reference to
the data access layer and return the relevant tables?

Sorry about the length of this post, but any help with any of the issues

here would be greatfully received. Any links to good reference material
would be useful too.

 

[Guest]

The Data Access Application Block is essentially just a set of static methods for just filling datasets. I have no problem writing this stuff myself (I am using postgres, so the SQL Server oriented code would have to be modified somewhat). This document unfortunately doesn't explain how database tables should be grouped together into datasets, and that sort of thing, which is where I am confused.

I have tried reading the Microsoft Patterns and Practices - Designing Data Tier Components and Passing Data Through Tiers, and it didn't really help me clarify things.

I wonder if really I am confusing the data access layer with the business layer; where the line is drawn between them is fuzzy to me.

 

[TJO]

Some points for you that I use:

I don't use TypedDataSets on account of the overhead involved - DAL should
be light and fast.
Make one DAL per table and make it responsible for Select, Delete, Update,
and Insert on that table only.
Stateless is best.
My DAL objects return DataTables (and DataAdapters) up to the BO layer.
My DAL objects manage DAL DataTables within its DataSet.

I am writing a fairly large database application for the first time, and

am finding it difficult to decide on how to create the data access layer. I
have tried reading as much as I can find about them on MSDN, but have found
conflicting views, and am now really quite confused.

For example, I am using typed datasets to store my data in. I have created

a data access layer class, that basically has a set of procedures that
accept a dataset, and fill it with some sort of data. These functions are
basically static and stateless.

Should the data access layer be stateful?

Should I instantiate a data access layer in my main() method at the start

of my application that basically fills my dataset when I first load my app,
and then just pass a reference to the data layer into my various forms?

I am finding it hard to know how to split up my database tables into

datasets - just for the part I am working on now, I have about 20 tables,
all of which are accessed from a single form. Should these just be in a
single dataset? Or should I split them into smaller subgroups. The problem I
see with this is that any relations between them will no longer exist! Also,
if I have other forms that want to use just one or two of these 20 tables,
should I create a separate dataset for them, or just use the reference to
the data access layer and return the relevant tables?

Sorry about the length of this post, but any help with any of the issues

here would be greatfully received. Any links to good reference material
would be useful too.

 

[Guest]

Some points for you that I use:

I don't use TypedDataSets on account of the overhead involved - DAL should
be light and fast.
Make one DAL per table and make it responsible for Select, Delete, Update,
and Insert on that table only.
Stateless is best.
My DAL objects return DataTables (and DataAdapters) up to the BO layer.

Why would you return data adapters up to the business layer? I thought the idea of the different layers was to separate out the database specific stuff? I though you would simply pass any updated tables back to the data layer, where it would update the database behind the scenes?

My DAL objects manage DAL DataTables within its DataSet.

Do you mean this? Do you mean you pass the datatables from you DAL back to your business layer, and then add them to a dataset?

Is the business layer stateful?

 

[igor]

I am writing a fairly large database application for the first time, and am finding it difficult to decide on how to create the data access layer. I have tried reading as much as I can find about them on MSDN, but have found conflicting views, and am now really quite confused.

For example, I am using typed datasets to store my data in. I have created a data access layer class, that basically has a set of procedures that accept a dataset, and fill it with some sort of data. These functions are basically static and stateless.

Should the data access layer be stateful?

Should I instantiate a data access layer in my main() method at the start of my application that basically fills my dataset when I first load my app, and then just pass a reference to the data layer into my various forms?

I am finding it hard to know how to split up my database tables into datasets - just for the part I am working on now, I have about 20 tables, all of which are accessed from a single form. Should these just be in a single dataset? Or should I split them into smaller subgroups. The problem I see with this is that any relations between them will no longer exist! Also, if I have other forms that want to use just one or two of these 20 tables, should I create a separate dataset for them, or just use the reference to the data access layer and return the relevant tables?

Sorry about the length of this post, but any help with any of the issues here would be greatfully received. Any links to good reference material would be useful too.

Pete

You should rethink other options also, using datasets is not the only
way to get the data from the database especially if that don't fits your
needs.
Under my experience I found datasets great in the case when I need to
display data in the form of grid, for all sorts of reporting and so on.
But when I need to have a lot of business logic between I found it much
easier to use custom business objects. Of course you need to write the
code for reading and saving the object from/to database.
Consider using a tool for object-relational mapping.
In his "Patterns of Enterprise Application Architecture" book Fowler has
a great classification of object-relational mapping patterns.

Igor