Data Access Layer Components and moving apps to production

[Guest]

I've been working with .NET for a while now, and have been straight-coding all my data access layers. I've seen a few tutorials about using the Component Class to drag-and-drop DataAdapters, Connections, etc. onto a component and it looks like this would be a quicker way to write the code.

However, my concerns are with the connection to the database. When you drag a connection onto the component class, it hardcodes my local workstation development database connection string into the class file (we don't develop against production servers). How can this be convenient when moving the app from my development machine, to the testing environment, and finally to a production server? Do I have to re-code the connection string into the component each time, or what am I missing? If there is an easy way to fix the connection string problem, does anyone know of any good C# tutorials on using this method of development?

Thanks...

 

[William Ryan eMVP]

Diggler:

You may want to add a config file with the 'correct' connection string for
testing, then set the dynamic property of whatever connection to it. You
can point your dataadapter to use this same connection, and the connection
string will be conisitently whatever's in the config file. This should help
if you aren' tfamiliar with dynamic props.
http://www.knowdotnet.com/articles/attributes.html


HTH,

Bill

I've been working with .NET for a while now, and have been straight-coding

all my data access layers. I've seen a few tutorials about using the
Component Class to drag-and-drop DataAdapters, Connections, etc. onto a
component and it looks like this would be a quicker way to write the code.

However, my concerns are with the connection to the database. When you

drag a connection onto the component class, it hardcodes my local
workstation development database connection string into the class file (we
don't develop against production servers). How can this be convenient when
moving the app from my development machine, to the testing environment, and
finally to a production server? Do I have to re-code the connection string
into the component each time, or what am I missing? If there is an easy way
to fix the connection string problem, does anyone know of any good C#
tutorials on using this method of development?

 

[jasonq]

I never use the visual tools in .Net because of the inflexibility it gives
you. I created my own data access layer which handles all of interaction to
the db. What makes having your own data access layer is that it
encapsulates the db interaction and it can be used in many projects. I
suggest you take a look at these links to get a better idea:

http://www.gotdotnet.com/Community/Workspaces/Workspace.aspx?id=c20d12b0-af52-402b-9b7c-aaeb21d1f431

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnbda/html/daab-rm.asp

Good Luck

I've been working with .NET for a while now, and have been straight-coding

all my data access layers. I've seen a few tutorials about using the
Component Class to drag-and-drop DataAdapters, Connections, etc. onto a
component and it looks like this would be a quicker way to write the code.

However, my concerns are with the connection to the database. When you

drag a connection onto the component class, it hardcodes my local
workstation development database connection string into the class file (we
don't develop against production servers). How can this be convenient when
moving the app from my development machine, to the testing environment, and
finally to a production server? Do I have to re-code the connection string
into the component each time, or what am I missing? If there is an easy way
to fix the connection string problem, does anyone know of any good C#
tutorials on using this method of development?

 

[Guest]

That's the way I've always done it too. I thought I might be missing something on some 'preferred way' to do it, and wondered if I were to get my C#/ASP.NET certs if I'd need to know it. Although I've never used it in day-to-day work.