Data Component, Data Layer

[Matt]

I am developing couple intranet site. Cant decide what to use to get
the Data
I will be using Data Layer to get,update, insert, delete and report
type queries..
Most expensive table will have 1 mil records.. Just a couple of tables
will have that amount of data..

What would be affecient to use between
1. Code behind to call SqlDataAdapter,SqlConnection,SqlCommand,DataSet
etc
2. Table Adapters with DataSet connected to Database
3. Own Writen Data.cs like dataComponent somesort..
4. Enterprise Library January 2006, Application Data Block

 

[Karthik D V]

I am developing couple intranet site. Cant decide what to use to get
the Data
I will be using Data Layer to get,update, insert, delete and report
type queries..
Most expensive table will have 1 mil records.. Just a couple of tables
will have that amount of data..

What would be affecient to use between
1. Code behind to call SqlDataAdapter,SqlConnection,SqlCommand,DataSet
etc
2. Table Adapters with DataSet connected to Database
3. Own Writen Data.cs like dataComponent somesort..
4. Enterprise Library January 2006, Application Data Block

If you are doing the modification on huge records, then #1 is the
better, if you are using the data only for display purpose then #3.

 

[sloan]

See

5/24/2006
Custom Objects/Collections and Tiered Development

6/5/2006
Custom Objects and Tiered Development II // 2.0


at:

http://sholliday.spaces.live.com/blog/


You can substitute the EnterpriseLibrary block where I have the SqlHelper
class.

The examples show how to write your own data layer, using SqlHelper (or
EnterpriseLibrary ) as the ~~~helper class.

 

[Matt]

Any other thought code behind vs Blocks vs Component modelize cs..
Pros and Cons ?

Thanks

 

[sloan]

There is a difference between rapid development and good development.

I side on good development, not rapid development.

The new "built in" stuff with the aspx code behind for database connectivity
is "rapid' in my book.
Fine for demo's or prototypes, not good for a software solution.

If you create a DataLayer object, and that object uses SqlHelper or
EnterpriseLibrary to "help" with data access, you're building a reusable
component, and its much easier to maintain.

In my sample, I think I have something like

OrderData
or
CustomerData

classes.

As the blog states, this returns IDataReaders, DataSets , scalars or voids.

The downloadable code is sitting there to learn from. The better you
architect up front, the more time you'll save in the long run.

Any other thought code behind vs Blocks vs Component modelize cs..
Pros and Cons ?

Thanks

quoted text -- Show quoted text -

 

[Mark Rae]

The new "built in" stuff with the aspx code behind for database
connectivity
is "rapid' in my book.
Fine for demo's or prototypes, not good for a software solution.

In fact I would venture to say that, when compared to a decent DAL, the new
SqlDataSource stuf is actually *slower* to develop with...

"New" doesn't always mean "better", IMO...

An example of this is the CustomValidator stuff - I've never found anything
in that that I couldn't do quicker and easier with my own JavaScript
validation scripts...

 

[sloan]

//
In fact I would venture to say that, when compared to a decent DAL, the new
SqlDataSource stuf is actually *slower* to develop with...

"New" doesn't always mean "better", IMO...
//


Amen.

 

[Mark Rae]

In fact I would venture to say that, when compared to a decent DAL, the
new
SqlDataSource stuf is actually *slower* to develop with...

"New" doesn't always mean "better", IMO...

I couldn't agree more!