Application wide information into classes in referenced DLL's
-
I am not sure the subject gives a clear indication of my problem/question. I am building a set of applications based on a common database. In order to facilitate this I have a VB.NET project that handles all of the database connectivity and manages the tables. One class in this project "Functionality" has methods for the actual database calls. The connection string is fixed in it. The other classes in this project are for each table in the database for save, loadrecord, etc. Each of these classes instantiates the Functionality class to select/insert/update. This project is compiled into a dll. Other projects which include a stand-alone programme to deal with repetitive tasks and a desktop application, reference the DLL and instantiate the tables classes as required to obtain data, and change it. Move forward and I now need the entire system to work with a second database. However the database is identical in structure. So the only change is the connectionstring. Obviously I can change this in the Functionality class, recompile the DLL. And recompile the applications and I have a version working with the new database. However, what I want is to be able to switch between the databases on the fly. And this is my problem. I need someway for the Functionality class to be able know which Database (M or T or A or S) is required by the application that instantiated a table class that is using the Functionality class. So, the Desktop application can have a Public Shared variable, but this can not be seen by the called method of the table class. If you understand this, is there anyway of doing what I want?
-
I am not sure the subject gives a clear indication of my problem/question. I am building a set of applications based on a common database. In order to facilitate this I have a VB.NET project that handles all of the database connectivity and manages the tables. One class in this project "Functionality" has methods for the actual database calls. The connection string is fixed in it. The other classes in this project are for each table in the database for save, loadrecord, etc. Each of these classes instantiates the Functionality class to select/insert/update. This project is compiled into a dll. Other projects which include a stand-alone programme to deal with repetitive tasks and a desktop application, reference the DLL and instantiate the tables classes as required to obtain data, and change it. Move forward and I now need the entire system to work with a second database. However the database is identical in structure. So the only change is the connectionstring. Obviously I can change this in the Functionality class, recompile the DLL. And recompile the applications and I have a version working with the new database. However, what I want is to be able to switch between the databases on the fly. And this is my problem. I need someway for the Functionality class to be able know which Database (M or T or A or S) is required by the application that instantiated a table class that is using the Functionality class. So, the Desktop application can have a Public Shared variable, but this can not be seen by the called method of the table class. If you understand this, is there anyway of doing what I want?
Store the connection string in the application's configuration file, and have the "functionality" class read it from there. Eg:
<?xml version="1.0" encoding="utf-8"?>
<configuration>
<connectionStrings>
<add
name="Functionality"
connectionString="........."
providerName="System.Data.SqlClient"
/>
</connectionStrings>
</configuration>Private Shared Function CreateConnection() As SqlConnection
Dim connectionString As String = ConfigurationManager.ConnectionStrings("Functionality").ConnectionString
Return New SqlConnection(connectionString)
End FunctionIf you need to access more than one database in a single application, you'll need to modify your classes so that you can pass in the connection string name somehow. You can still read the actual connection string from the configuration file.
"These people looked deep within my soul and assigned me a number based on the order in which I joined." - Homer
-
I am not sure the subject gives a clear indication of my problem/question. I am building a set of applications based on a common database. In order to facilitate this I have a VB.NET project that handles all of the database connectivity and manages the tables. One class in this project "Functionality" has methods for the actual database calls. The connection string is fixed in it. The other classes in this project are for each table in the database for save, loadrecord, etc. Each of these classes instantiates the Functionality class to select/insert/update. This project is compiled into a dll. Other projects which include a stand-alone programme to deal with repetitive tasks and a desktop application, reference the DLL and instantiate the tables classes as required to obtain data, and change it. Move forward and I now need the entire system to work with a second database. However the database is identical in structure. So the only change is the connectionstring. Obviously I can change this in the Functionality class, recompile the DLL. And recompile the applications and I have a version working with the new database. However, what I want is to be able to switch between the databases on the fly. And this is my problem. I need someway for the Functionality class to be able know which Database (M or T or A or S) is required by the application that instantiated a table class that is using the Functionality class. So, the Desktop application can have a Public Shared variable, but this can not be seen by the called method of the table class. If you understand this, is there anyway of doing what I want?
Use an "interface". You can have a static that references an interface (of an object) that you set at runtime to your primary database class from the appropriate Dll (i.e. the "repository"). Windows, in a number of cases, has a "Current" static that references the "app", "main window", etc. The same holds true for your app if you "know" there can only be ONE active repository, or weigh scale, or whatever. If you already have 2 "database" dlls, I assume there are 2 namespaces; the interface goes into a different namespace from the previous 2 for it to "work". (and maybe it's just the "connection" component you put in a separate dll and interface (if you want it hard-coded); the rest of the db code can be in the same name space if it's shareable).
It was only in wine that he laid down no limit for himself, but he did not allow himself to be confused by it. ― Confucian Analects: Rules of Confucius about his food
-
I am not sure the subject gives a clear indication of my problem/question. I am building a set of applications based on a common database. In order to facilitate this I have a VB.NET project that handles all of the database connectivity and manages the tables. One class in this project "Functionality" has methods for the actual database calls. The connection string is fixed in it. The other classes in this project are for each table in the database for save, loadrecord, etc. Each of these classes instantiates the Functionality class to select/insert/update. This project is compiled into a dll. Other projects which include a stand-alone programme to deal with repetitive tasks and a desktop application, reference the DLL and instantiate the tables classes as required to obtain data, and change it. Move forward and I now need the entire system to work with a second database. However the database is identical in structure. So the only change is the connectionstring. Obviously I can change this in the Functionality class, recompile the DLL. And recompile the applications and I have a version working with the new database. However, what I want is to be able to switch between the databases on the fly. And this is my problem. I need someway for the Functionality class to be able know which Database (M or T or A or S) is required by the application that instantiated a table class that is using the Functionality class. So, the Desktop application can have a Public Shared variable, but this can not be seen by the called method of the table class. If you understand this, is there anyway of doing what I want?
What you are asking about is the Data Access Layer (DAL - use this for your Google Foo). There are many articles and examples about this available. As Richard said pass in your connection string, remember you need to move from development DB to production DB at some time!
Never underestimate the power of human stupidity - RAH I'm old. I know stuff - JSOP
-
Store the connection string in the application's configuration file, and have the "functionality" class read it from there. Eg:
<?xml version="1.0" encoding="utf-8"?>
<configuration>
<connectionStrings>
<add
name="Functionality"
connectionString="........."
providerName="System.Data.SqlClient"
/>
</connectionStrings>
</configuration>Private Shared Function CreateConnection() As SqlConnection
Dim connectionString As String = ConfigurationManager.ConnectionStrings("Functionality").ConnectionString
Return New SqlConnection(connectionString)
End FunctionIf you need to access more than one database in a single application, you'll need to modify your classes so that you can pass in the connection string name somehow. You can still read the actual connection string from the configuration file.
"These people looked deep within my soul and assigned me a number based on the order in which I joined." - Homer
Thanks for answering. However, it didn't answer the question it told me something I knew - which is why I had the problem. What it did do is highlight that there isn't an answer, which is what I thought.
-
Use an "interface". You can have a static that references an interface (of an object) that you set at runtime to your primary database class from the appropriate Dll (i.e. the "repository"). Windows, in a number of cases, has a "Current" static that references the "app", "main window", etc. The same holds true for your app if you "know" there can only be ONE active repository, or weigh scale, or whatever. If you already have 2 "database" dlls, I assume there are 2 namespaces; the interface goes into a different namespace from the previous 2 for it to "work". (and maybe it's just the "connection" component you put in a separate dll and interface (if you want it hard-coded); the rest of the db code can be in the same name space if it's shareable).
It was only in wine that he laid down no limit for himself, but he did not allow himself to be confused by it. ― Confucian Analects: Rules of Confucius about his food
Thank you. Whilst I am not sure I would use an Interface to achieve what I need to do, you have helped me solve my problem. Using Process I can see the main window's title from the instantiated class, because it is in the myprocess. As long as I have what I need there I can do it. It would be nice to be able to create a property on the process that I could see as easy to see it would be great.
Dim pReturn As Process
pReturn = Process.GetCurrentProcess()
cKey = (Left(pReturn.MainWindowTitle, 3)All that is needed is a Select Case and I can change to the appropriate connection string for the company using the programme. Thanks again.
-
What you are asking about is the Data Access Layer (DAL - use this for your Google Foo). There are many articles and examples about this available. As Richard said pass in your connection string, remember you need to move from development DB to production DB at some time!
Never underestimate the power of human stupidity - RAH I'm old. I know stuff - JSOP
Yes, that would have been a route. But it isn't one I needed for this application. What I didn't say is this is entirely an in house set of applications. Used to run this business. We have acquired another business and they too will run the applications - but against a different database, on the same server. Writing something to pass the database name in to the class would have required hours of writing to change all times this class is instantiated. Because it is in house I have hither to simply changed the CN string in the class before compiling everything to switch from test to production databases. The system is running, and being developed and new things are added - that is constant.
-
Thank you. Whilst I am not sure I would use an Interface to achieve what I need to do, you have helped me solve my problem. Using Process I can see the main window's title from the instantiated class, because it is in the myprocess. As long as I have what I need there I can do it. It would be nice to be able to create a property on the process that I could see as easy to see it would be great.
Dim pReturn As Process
pReturn = Process.GetCurrentProcess()
cKey = (Left(pReturn.MainWindowTitle, 3)All that is needed is a Select Case and I can change to the appropriate connection string for the company using the programme. Thanks again.
I would not rely on the Main Window Title; any application can pretend to be your target. If you can find the proces, then you can find the executable that is being executed. At that point, you can load that assembly and query its assembly-attributes.
Bastard Programmer from Hell :suss: If you can't read my code, try converting it here[^] "If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
-
Yes, that would have been a route. But it isn't one I needed for this application. What I didn't say is this is entirely an in house set of applications. Used to run this business. We have acquired another business and they too will run the applications - but against a different database, on the same server. Writing something to pass the database name in to the class would have required hours of writing to change all times this class is instantiated. Because it is in house I have hither to simply changed the CN string in the class before compiling everything to switch from test to production databases. The system is running, and being developed and new things are added - that is constant.
Presuming the application is a desktop solution, hopefully using click once deployment. Your DAL should be included in each application project either as a DLL or a referenced project (I usually referenced the project to make debugging easier). EVERY database interaction should go through the DAL using the connection string supplied by the config file. You should only need to change the CN once for each deployment type (production/UAT/development) and this can be automated using compile directives.
A D Rosser wrote:
Writing something to pass the database name in to the class would have required hours of writing to change all times this class is instantiated.
This makes me think each table class interacts directly with the database, a thoroughly nasty situation. Changing to use a DAL does not have to be a singular task, all new operations should use the DAL and put a junior on changing the existing classes.
Never underestimate the power of human stupidity - RAH I'm old. I know stuff - JSOP
-
Thank you. Whilst I am not sure I would use an Interface to achieve what I need to do, you have helped me solve my problem. Using Process I can see the main window's title from the instantiated class, because it is in the myprocess. As long as I have what I need there I can do it. It would be nice to be able to create a property on the process that I could see as easy to see it would be great.
Dim pReturn As Process
pReturn = Process.GetCurrentProcess()
cKey = (Left(pReturn.MainWindowTitle, 3)All that is needed is a Select Case and I can change to the appropriate connection string for the company using the programme. Thanks again.
