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

Matt wrote:
> 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.

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" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> 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
>

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

Thanks



On Jan 4, 10:53 am, "sloan" <s...@ipass.net> wrote:
> 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" <meteha...@Hotmail.com> wrote in messagenews:(E-Mail Removed)...
>
>
>
> > 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- Hide quoted text -- Show quoted text -

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.




"Matt" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> Any other thought code behind vs Blocks vs Component modelize cs..
> Pros and Cons ?
>
> Thanks
>
>
>
> On Jan 4, 10:53 am, "sloan" <s...@ipass.net> wrote:
> > 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" <meteha...@Hotmail.com> wrote in
messagenews:(E-Mail Removed)...
> >
> >
> >
> > > 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- Hide
quoted text -- Show quoted text -
>

"sloan" <(E-Mail Removed)> wrote in message
news:%(E-Mail Removed)...

> 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...

//
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" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> "sloan" <(E-Mail Removed)> wrote in message
> news:%(E-Mail Removed)...
>
> > 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" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...

> 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!