C# with Access database curiosity 1

[ethorn10]

I have just inherited a web app written in c# with an Access database behind it. Prior to this, I was writing an app in ASP.NET using VB and SQL Server 2000 so maybe I'm biased but here goes:

The database is relatively small (22 tables) and the app uses OO wonderfully. However, as I'm trying to get my head wrapped around the thing, it seems like there is TONS of overkill (perhaps it is just a good DAL?). There is one class that handles data management (e.g. fills a dataset, updates the db, creates the adapter) and another class (let's call it mydataset.cs) that seems to just recreate the database as classes.

mydataset.cs creates a new class for each table. So, table1 would be 'public class table1data : DataTable' which then has each column instantiated as a private DataColumn.

So I guess I'm just looking for input. Is this reinventing the wheel to a laughable level or is it an awesome data access layer?

 

[dominus1]

I never heard of creating a class per table. Maybe you should consider removing that layer of extraction. The classes in the data layer should make logical sense rather then randomly creating one class per table.

 

[ca8msm]

You should have one class per entity. Whether an entity maps directly to one table is probably down to the design of the database.


-------------------------------------------------------

Mark,
[URL unfurl="true"]http://aspnetlibrary.com[/url]
[URL unfurl="true"]http://mdssolutions.co.uk[/url] - Delivering professional ASP.NET solutions
[URL unfurl="true"]http://weblogs.asp.net/marksmith[/url]

 

[ethorn10]

So the point of the DataTable class is to be instantiated as a new name for each table as opposed to accepting a tablename and creating a local variable as necessary?

Like I said, this is a fairly small database but still, any structure change requires quite a bit of duplicity on the .NET class.

And again, maybe I'm biased and not being very open-minded about this but really??

 

[ca8msm]

So the point of the DataTable class is to be instantiated as a new name for each table as opposed to accepting a tablename and creating a local variable as necessary?

I'm not sure what you are aasking here.

What I usually do is have 3 layers:

Presentation Layer (PAL)
Business Layer (BAL)
Database Access Layer (DAL)

In short, my PAL will make a call to the BAL, and the BAL will get the data from the DL and return it to the PAL.

My database layer will return the relevant information in a format such as an Integer, String, DataTable, DataReader etc. The BAL will then construct an entity (say for example a "product" which has and "id" and "name" property) based on the information in the DataTable (or whatever relevant object). This entity (it's basically a class if you'd prefer to think of it like that) is then returned to the PAL and bound to the relevant data control.

Is that similar to what you are seeing, or is it more complicated than that?




-------------------------------------------------------

Mark,
[URL unfurl="true"]http://aspnetlibrary.com[/url]
[URL unfurl="true"]http://mdssolutions.co.uk[/url] - Delivering professional ASP.NET solutions
[URL unfurl="true"]http://weblogs.asp.net/marksmith[/url]

 

[ethorn10]

In short, I think it is more complicated than that.

To make a short story long, I understand and advocate creating some generic databinding routines but this seems ridiculous. For simplicity, let's say we have 3 tables each with 2 columns:

table1 (column1, column2)
table2 (column1, column2)
table3 (column1, column2)

So in this one .cs file, the previous programmer has created three new classes:

public class table1data : DataTable, System.Collections.IEnumerable {
   private DataColumn column1;
   private DataColumn column2;
}
public class table2data : DataTable, System.Collections.IEnumerable {
   private DataColumn column1;
   private DataColumn column2;
}
public class table3data : DataTable, System.Collections.IEnumerable {
   private DataColumn column1;
   private DataColumn column2;
}

There is more but I swore simplicity

Any more insight? I truly appreciate your opinions thus far.

 

[ca8msm]

Ok, I see.

Personally, I don't see the point. I can't see what use a class for a table would be. If, the class represented something, i.e. table1 was called product and had an id and name, then it's useful as that product will be used around the site.

Actual 1:1 table mappings are probably not as useful, although do you know that it's the developer who has done this? Some tools will automate this for you in an attempt to save you time.


-------------------------------------------------------

Mark,
[URL unfurl="true"]http://aspnetlibrary.com[/url]
[URL unfurl="true"]http://mdssolutions.co.uk[/url] - Delivering professional ASP.NET solutions
[URL unfurl="true"]http://weblogs.asp.net/marksmith[/url]

 

[ethorn10]

Unfortunately, I'm just assuming he's the culprit as I don't know of any tools he may have used for automation. I'm glad to hear you say that you don't see the point. I just wondered if my bias was getting in my way -- I'm fine with 10,000 line .cs/.vb files when they accomplish something useful. I was just always under the impression that you create a generic binding routine that accepts tablenames, what object will be bound, etc. and call it when needed...NOT duplicate the database into classes/members/etc.

Thank you and feel free to add more if you have it.

 

[ethorn10]

Another day, a little more digging ...

It looks like the previous guy decided to load all data (and yes I mean ALL) into their respective DataSet class (remember how each has its own class) basically on page_load. This to me is nonsense and can display stale datasets depending on the user load, etc. I'm trying to figure out why he would have done it this way (outside of just not knowing any better) ... could it have to do with the locking that happens on Access databases? I know that Access isn't ideal for web apps for this very reason (among others) but is THIS really the solution?