move all data access to component(s)?

I'm thinking about moving all my data access to components that will return a
series of record sets, data readers, scaler. The pages will create an
instance of a record set to be filled by functions. Updates will be functions
with datarows or recordsets as parameters.
Am i going too far?
Will this slow down that app or make it unnecessarly big?

i like some advice on this
(I still new at this, but i'm getting there)
thanks
kes

William
Tue Aug 02 10:39:35 CDT 2005

Will a custom object interface slow down your application? Sure. But by how
much is the question. It depends on a host of factors including how well the
interface is written.
Will it make it bigger? Sure. To some degree--with the same caveats.
Will it make it better? Perhaps. What is "better"? More competitive? Only
maybe. It won't be faster. It won't load any faster or run any faster. It
won't be as scalable because it consumes more resources per user.
Will it make it easier to port between database engines? It could if it's
done right.
Will it make it harder for someone new to your company to program? Perhaps.
They might have to learn your OO interface as well as ADO.NET. You might
also be able to segment the application more easily, but you can do that
without an object interface.

hth


--
____________________________________
William (Bill) Vaughn
Author, Mentor, Consultant
Microsoft MVP
www.betav.com/blog/billva
www.betav.com
Please reply only to the newsgroup so that others can benefit.
This posting is provided "AS IS" with no warranties, and confers no rights.
__________________________________

"WebBuilder451" <WebBuilder451@discussions.microsoft.com> wrote in message
news:2ABDC146-4631-4746-BD39-AA1FF341F304@microsoft.com...
> I'm thinking about moving all my data access to components that will
> return a
> series of record sets, data readers, scaler. The pages will create an
> instance of a record set to be filled by functions. Updates will be
> functions
> with datarows or recordsets as parameters.
> Am i going too far?
> Will this slow down that app or make it unnecessarly big?
>
> i like some advice on this
> (I still new at this, but i'm getting there)
> thanks
> kes

WebBuilder451
Tue Aug 02 11:51:03 CDT 2005

thanks
I've seen some talk of this sort of thing being done. I'd like to build an
object that can just be included as needed for simple things like filling a
ddl with states (example only). I like the idea, but i need it to be
practical.
thank you
kes


"William (Bill) Vaughn" wrote:

> Will a custom object interface slow down your application? Sure. But by how
> much is the question. It depends on a host of factors including how well the
> interface is written.
> Will it make it bigger? Sure. To some degree--with the same caveats.
> Will it make it better? Perhaps. What is "better"? More competitive? Only
> maybe. It won't be faster. It won't load any faster or run any faster. It
> won't be as scalable because it consumes more resources per user.
> Will it make it easier to port between database engines? It could if it's
> done right.
> Will it make it harder for someone new to your company to program? Perhaps.
> They might have to learn your OO interface as well as ADO.NET. You might
> also be able to segment the application more easily, but you can do that
> without an object interface.
>
> hth
>
>
> --
> ____________________________________
> William (Bill) Vaughn
> Author, Mentor, Consultant
> Microsoft MVP
> www.betav.com/blog/billva
> www.betav.com
> Please reply only to the newsgroup so that others can benefit.
> This posting is provided "AS IS" with no warranties, and confers no rights.
> __________________________________
>
> "WebBuilder451" <WebBuilder451@discussions.microsoft.com> wrote in message
> news:2ABDC146-4631-4746-BD39-AA1FF341F304@microsoft.com...
> > I'm thinking about moving all my data access to components that will
> > return a
> > series of record sets, data readers, scaler. The pages will create an
> > instance of a record set to be filled by functions. Updates will be
> > functions
> > with datarows or recordsets as parameters.
> > Am i going too far?
> > Will this slow down that app or make it unnecessarly big?
> >
> > i like some advice on this
> > (I still new at this, but i'm getting there)
> > thanks
> > kes
>
>
>

Cor
Tue Aug 02 12:00:26 CDT 2005

WebBuilder,

You want to use recordsets and datarows. I don't believe that mixing up
adodb and adonet in the same component will give you much pleasure. At least
would I keep those apart.

Just my thought,

Cor

WebBuilder451
Tue Aug 02 12:26:02 CDT 2005

it may make coding easer for common tasks like loading controls that require
state listings (not the best example , but it is the idea)
(is ther a short hand way to close a datareader on execute? I seem to
remember some one doing this )

function:
Function fn_getStates() As SqlDataReader
Dim drSta As SqlDataReader
Dim stacmd As SqlCommand = Me.SqlConnection1.CreateCommand
stacmd.CommandType = CommandType.StoredProcedure
stacmd.CommandText = "sp_GetStates"
Me.SqlConnection1.Open()
Return stacmd.ExecuteReader
End Function

load the state.
Sub load_ddls()
Dim thscon As siteConstants = New siteConstants
Me.ddlState.DataSource = thscon.fn_getStates
Me.ddlState.DataValueField = "staShort"
Me.ddlState.DataTextField = "staDesc"
Me.ddlState.DataBind()
End Sub

thanks
kes

"Cor Ligthert [MVP]" wrote:

> WebBuilder,
>
> You want to use recordsets and datarows. I don't believe that mixing up
> adodb and adonet in the same component will give you much pleasure. At least
> would I keep those apart.
>
> Just my thought,
>
> Cor
>
>
>

Cor
Tue Aug 02 12:33:19 CDT 2005

WebBuilder,

There is nothing agains creating components (classes) for your default
tasks, it is even recomendend. However as I asked, why mixing up AdoDb
things as a recordet with ADONET things as AdoNet in in those components.
They will seldom be used in the same place.

You use an AdoDb Recordset or you use an AdoNet DataTable with DataRows.

Cor

WebBuilder451
Tue Aug 02 13:56:58 CDT 2005

Thanks for responding. This discussion has been VERY helpful.
This does raise another issue i had some concerns about.
I would like to use quick datareaders for filling dropdowns. I don't see a
need to include a data set for a drop down, seems like over kill and unneeded
over head. However for customer records and/or orders a dataset would make
more sense because i could create a new row object off the dataset, add the
fields, then insert (the strong typing makes it easer). for updates grab the
rows update then flush back to the database when done.

I was planning to build a series of functions in a "single" component. to
do all this. Here iare my issues
1. should they all be in seprate components (assemblies(?)) or in a single?
2. does the compiler create complete instances of all functions, ... when
there are created, but only one function is used?
3. can (forgive this if the answer is ovbious) I create a single instance
and make it global for the page then just call the functions as needed?

thanks again, I appreciate your taking the time to answer.
kes

"Cor Ligthert [MVP]" wrote:

> WebBuilder,
>
> There is nothing agains creating components (classes) for your default
> tasks, it is even recomendend. However as I asked, why mixing up AdoDb
> things as a recordet with ADONET things as AdoNet in in those components.
> They will seldom be used in the same place.
>
> You use an AdoDb Recordset or you use an AdoNet DataTable with DataRows.
>
> Cor
>
>
>

Cor
Tue Aug 02 14:30:01 CDT 2005

WebBuilder,

In this are differences for Web and WindowsForms.

> Thanks for responding. This discussion has been VERY helpful.
> This does raise another issue i had some concerns about.
> I would like to use quick datareaders for filling dropdowns.

For the web I don't see any advance using a dataset above a datareader for a
drop down.
For controls as a datagrids, that has to be updated I prefer the datatable
(as it is a part of a dataset) above a datareader.

Be aware that a dataset does not hold datarows, that does the datatable
which is holded by the dataset.

> 1. should they all be in seprate components (assemblies(?)) or in a
> single?

Everything on a webpage goes directly out of scope. The applications belongs
to all active clients and is active until there are no more client for that
application are active.

I think that this should be the major point of your decissions in what you
do.

Don't think in functions however in classes that you can instance. I would
not create one class with everything in it, however more classes. Have a
look at the architecture of the namespace system.data (AdoNet), maybe is
that a fine sample, and you learn in the same time more from ADONET.

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpref/html/frlrfsystemdata.asp

I hope this helps

Cor

WebBuilder451
Tue Aug 02 15:41:06 CDT 2005

Thank you,
this is a big help. your answer seems to follow with what i thought.
IOU1
kes

"Cor Ligthert [MVP]" wrote:

> WebBuilder,
>
> In this are differences for Web and WindowsForms.
>
> > Thanks for responding. This discussion has been VERY helpful.
> > This does raise another issue i had some concerns about.
> > I would like to use quick datareaders for filling dropdowns.
>
> For the web I don't see any advance using a dataset above a datareader for a
> drop down.
> For controls as a datagrids, that has to be updated I prefer the datatable
> (as it is a part of a dataset) above a datareader.
>
> Be aware that a dataset does not hold datarows, that does the datatable
> which is holded by the dataset.
>
> > 1. should they all be in seprate components (assemblies(?)) or in a
> > single?
>
> Everything on a webpage goes directly out of scope. The applications belongs
> to all active clients and is active until there are no more client for that
> application are active.
>
> I think that this should be the major point of your decissions in what you
> do.
>
> Don't think in functions however in classes that you can instance. I would
> not create one class with everything in it, however more classes. Have a
> look at the architecture of the namespace system.data (AdoNet), maybe is
> that a fine sample, and you learn in the same time more from ADONET.
>
> http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpref/html/frlrfsystemdata.asp
>
> I hope this helps
>
> Cor
>
>
>