I've used Delphi for the past 12 years, but now I need to get up to speed in C#. Since both systems were designed by the same person, there are lots of similarities. However, C# seems to have a big gap when it comes to centralized data access. All of the examples I've seen show the connections, commands and datasets and so forth all being placed on individual forms with no interconnection.

The applications I work with have numerous primary and support tables with related queries and so on. If I have to redelcare these in every form where they are used, the code overhead will be huge and maintenance becomes a nightmare because I must make changes in multiple locations.

Delphi provides a container class called a 'data module' where connections and data access components can be installed during design. Data modules are also used to hold support code for events, business rules and so forth all in one place. Once defined, data aware controls in forms or other units can access those components as need be either during design or run time. This obviously reduces code and makes design and maintenace much easier.

I am assuming there is some way to do this, or at least achieve the same end, in .NET. However, I haven't come across an answer yet. Can anyone point me in the right direction? I don't want to do any serious work until I figure this problem out. Thanks.

i ran into an issue such as this a while back and ended up just writing a library to handle all SQL connections so that all forms had a central method for running their methods.

i ran into an issue such as this a while back and ended up just writing a library to handle all SQL connections so that all forms had a central method for running their methods.

I was afraid that might be the answer.

I am also a convert from Delphi (started with D1, ended with D2005).

There are many ideas out there on how to centralize your data. The idea of a Data Module is not as foreign to C# as you might think. After all, a TDataModule is nothing more than a Class with functions, procedures, Properties and the ability to include public DataSets, public TADOConnection, etc. A TDataModule in Delphi is developed by the programmer with a specific task in mind. Lets say the data components allow for accessing payroll information. In Delphi you typically try to encapulate the data access and attributes of the payroll system within your TDataModule.

A C# class is all of that and more. You can create a new class for your application, and think of it just like a TDataModule. Add your public variables or components just like in Delphi. For instance, you can instanciate an SqlConnection in the same way you instanciate a TAdoConnection.

It takes some getting used to, and some things take more code than in Delphi, but I find that c# is more powerful, and getting a forward only dataset is much faster in dot-Net than ADO or BDE in Delphi.

BTW: I still work with Delphi everyday in support of our legacy product. I am also working on the new development projects in C#.


That is a little more encouraging. However, you didn't say if you got to the point that you could link data objects to your forms and reports at design time, and if you were able to create reusable classes or had to custom code each 'data module'. I'm sure that's all possible if I want to delve deeply enough into NET (though far more difficult since I don't have the code). For the moment, I will do what I need in code alone, I guess.

I am working with data for natural resources which involves lots of tables with lots of fields and lots of interrelations, so hand-coding everything is quite a chore. I'm finding that the amount of code required in C# is a LOT larger than Delphi. NET may well be more powerful than VCL, but I find it much harder to handle as well.

when in the C# Editor add a new class,

build that class as you need.

then you can simply reference that class in any other class/form as needed.

i'll write you an example write now!

cheers! :-)


Also if you have any questions regarding what you are trying to acheive i may be able to point you in a direction that will reduce the ammount of code you are using.

One huge advantage of C# is that it can use libraries from most any languages as long as they are built correctly. I find myself most commonly referencing C++ libraries to handle tasks that would otherwise require more code than normal.

using System;
using System.Collections.Generic;
using System.Text;
using System.Data.Odbc;
namespace ConnectionSharing
    class SqlConnectionManager : IDisposable
        public SqlConnectionManager() {
            if (ConnectionSharing.Properties.Settings.Default.OdbcSqlConnection == null)
                //you may place any initializer code in here
                //create our connection string
                 * Driver: The built in Driver to use, for 
                 *         non standard databases this must 
                 *         be installed and setup prior to calling
                 * Server: The location of the server, mine
                 *         happens to be on the local host
                 * Database: Not specified but is recommended 
                 *          if you wish to use for specific reasons
                 * Uid: The user ID of the person connecting 
                 *          specified by the global variables
                 * Pwd: The password of the person connecting 
                 *          specified by the global variables
                string openSqlConnection =
                        @"Driver=(SQL Server);Server=Localhost;uid=" + ConnectionSharing.Properties.Settings.Default.Username +
                        ";Pwd=" + ConnectionSharing.Properties.Settings.Default.Password + ";";
                //please note that the @ sign on the preceeding line means to interpret the string literally
                this.x_sqlConnection = new OdbcConnection(openSqlConnection);
        //now any methods you create have access to the SQL connection created
        private OdbcConnection x_sqlConnection = null;
        //always supply a dispose method when working with disposable objects
        public void Dispose() {
            //cleanup / close the connection

you can now reference this class from any other form/class you create and not have to re-write your code for common tasks.

one option would be to create another application setting which contained the OdbcConnection object this way each time the class was called from a new form it would simply check to see if the object existed and had an open connection, the SqlConnectionManager would simply reuse the pre-existing OdbConnection even though it the class was called as a new instance.

Hey guys

Dont reinvent the wheel :) the guys at Microsoft have developed a central data access layer and other useful stuff. It is in their applications blocks in Patterns and Practices and there are many useful blocks in there to use. All of them are proven and very useful in enterprise applications

http://msdn2.microsoft.com/en-us/practices/bb190359.aspx is where to find them all :)

I finally got back to looking at this problem. From what I see in the replies, I can build a class to be used in various parts of a program. While that is useful, I see no way to create a single instance of that class to be used throughout the program. I am looking a a database with nearly 100 different tables (and probably nearly that many forms to handle them). Yeah, I can use the class in every place I need it, which saves a lot of code, but each time will be a new instance. That is pretty weak, as I can't make use of common states and so on.

Is there any way to instantiate a class outside of a form for use throughout a program?

Create a public static class in your main namespace, and you will have access to it from all objects / forms that use that namespace. You can store state-full information in static vars and collections within that class.

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.