Accessing Shared Properties of a Parent Windows App from Class Lib

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

I have a windows app that instantiates custom objects from a class library
many times over and over. Each object interacts with the database and must
create, open, and close the database connections as needed. As you can
imagine, this is very inefficient when working with a database.

I would like to create one database connection that is shared among my
objects. Short of sending this connection to each object when I instantiate
them, what can I do to simplify this process to allow all instantiated
objects to use a single database connection?

Example of what I don't want to have to do for every custom object instance:
Dim oDBConnection as new SQLConnection(MyConnectionString)
Dim oMyObject as new MyLibrary.MyObject(oDBConnection)

Example of what I would like to do:
(main forms app)
Protected Shared DBConnection as new SQLConnection(MyConnectionString)
Dim oMyObject as new MyLibrary.MyObject

(inside MyObject new constructor)
Private oConn as SQLConnection
Public Sub New()
' Go get the db connection from the parent calling windows app
oConn = (someblackmagic).DBConnection
End Sub

So, where you see (someblackmagic) I would like to somehow get that
DBConnection from the calling assembly's (windows app) Shared variable
DBConnection.

Any help would be greatly appreciated.
 
Hi Jon,

Based on my understanding, your winform application is creating some other
class library objects to implement business logic. All these class library
objects need the SQLConnection object to manipulate the database. So you
want to find a way to create the SQLConnection once and share it with all
the class library objects for efficiency. If I have misunderstood you,
please feel free to tell me, thanks.

Yes, this is a common task. The keypoint in this task is that how to get the
reference to the mainform object. There are several ways to get it done. For
example:
1. You may change the declaration of shared DBConnection object from
"Protected" to "Public". Then in each MyLibrary.MyObject constructor, you
may refer this shared DBConnection object with
"[mainForm_classname].DBConnection". This is because the "DBConnection" is a
shared object, there is no need to refer it with mainform object reference,
the mainform class name is enough to refer the public shared field/member.

2. In declaring the MyLibrary.MyObject constructor, you may add an extra
parameter of type DBConnection. Then whenever you are creating the
MyLibrary.MyObject in man form, you may pass the DBConnection object
reference in it. In this approach, there is no need to mark the
"DBConnection" as "shared".

3. If you are using VB2005, the VB2005 compiler provided a new featured
named "My Namespace". This feature allows us to refer a lot of useful
members staticly without the object references. So you may just use
"My.Forms[0]" to get the mainform reference in the MyLibrary.MyObject
constructor, then you may cast the reference into the mainform type(since
the reference you have got is of base type "Form"). Finally, you may use the
"mainform_reference.DBConnection" to get the DBConnection object now. In
this approach, there is no need to mark the "DBConnection" as "shared".
Please see the "The My Namespace" section in the article below for more
information regarding this new feature:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnvs05/html/vb2005_overview.asp

Additionally, if you are curious about how VB2005 compiler implement this
cool "My Namespace" feature, I have provided some insight in the discussion
thread below, just for your reference:
http://groups.google.com/group/micr...Jeffrey+Tan"&rnum=1&hl=zh-CN#cf909a3a4963b1e7

Hope this helps.

Best regards,
Jeffrey Tan
Microsoft Online Community Support
==================================================
Get notification to my posts through email? Please refer to
http://msdn.microsoft.com/subscriptions/managednewsgroups/default.aspx#notifications.

Note: The MSDN Managed Newsgroup support offering is for non-urgent issues
where an initial response from the community or a Microsoft Support Engineer
within 1 business day is acceptable. Please note that each follow up
response may take approximately 2 business days as the support professional
working with you may need further investigation to reach the most efficient
resolution. The offering is not appropriate for situations that require
urgent, real-time or phone-based interactions or complex project analysis
and dump analysis issues. Issues of this nature are best handled working
with a dedicated Microsoft Support Engineer by contacting Microsoft Customer
Support Services (CSS) at
http://msdn.microsoft.com/subscriptions/support/default.aspx.
==================================================
This posting is provided "AS IS" with no warranties, and confers no rights.
 
Thank you Jeff. That is very good information and would be very relevant if
my class library was in the same project as my windows forms. Unfortunately,
my class library is a stand-alone class library and is its own VS 2005
Project. My Windows Forms app is its own project, and my Windows Service is
its own project. All three of these projects are contained in one VS 2005
Solution. Both projects have a reference to my class library project, since
they both use the same objects.

My class library doesn't have the 'My.Forms' namespace available, because it
doesn't have any Windows Forms in it. I can't add a reference to the Windows
Forms project from my Class Library, because that would cause a circular
reference.

So does that leave me with only option 2 from your message; individually
send a SQLConnection reference for each call to my DB Connection object?
Isn't there anyway that I can reference the calling assemblies main form
properties from an instantiated external child class? Something like...

(from my db connection object within my external class library)
Me.GetType.Assembly.GetCallingAssembly.xxx.xxx.MainForm.DBConnection

Where xxx.xxx would be some reference to the main form somehow?

Thanks for your valuable input.
--
Jon Ebersole
Microsoft Certified Solution Developer


Jeffrey Tan said:
Hi Jon,

Based on my understanding, your winform application is creating some other
class library objects to implement business logic. All these class library
objects need the SQLConnection object to manipulate the database. So you
want to find a way to create the SQLConnection once and share it with all
the class library objects for efficiency. If I have misunderstood you,
please feel free to tell me, thanks.

Yes, this is a common task. The keypoint in this task is that how to get the
reference to the mainform object. There are several ways to get it done. For
example:
1. You may change the declaration of shared DBConnection object from
"Protected" to "Public". Then in each MyLibrary.MyObject constructor, you
may refer this shared DBConnection object with
"[mainForm_classname].DBConnection". This is because the "DBConnection" is a
shared object, there is no need to refer it with mainform object reference,
the mainform class name is enough to refer the public shared field/member.

2. In declaring the MyLibrary.MyObject constructor, you may add an extra
parameter of type DBConnection. Then whenever you are creating the
MyLibrary.MyObject in man form, you may pass the DBConnection object
reference in it. In this approach, there is no need to mark the
"DBConnection" as "shared".

3. If you are using VB2005, the VB2005 compiler provided a new featured
named "My Namespace". This feature allows us to refer a lot of useful
members staticly without the object references. So you may just use
"My.Forms[0]" to get the mainform reference in the MyLibrary.MyObject
constructor, then you may cast the reference into the mainform type(since
the reference you have got is of base type "Form"). Finally, you may use the
"mainform_reference.DBConnection" to get the DBConnection object now. In
this approach, there is no need to mark the "DBConnection" as "shared".
Please see the "The My Namespace" section in the article below for more
information regarding this new feature:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnvs05/html/vb2005_overview.asp

Additionally, if you are curious about how VB2005 compiler implement this
cool "My Namespace" feature, I have provided some insight in the discussion
thread below, just for your reference:
http://groups.google.com/group/micr...Jeffrey+Tan"&rnum=1&hl=zh-CN#cf909a3a4963b1e7

Hope this helps.

Best regards,
Jeffrey Tan
Microsoft Online Community Support
==================================================
Get notification to my posts through email? Please refer to
http://msdn.microsoft.com/subscriptions/managednewsgroups/default.aspx#notifications.

Note: The MSDN Managed Newsgroup support offering is for non-urgent issues
where an initial response from the community or a Microsoft Support Engineer
within 1 business day is acceptable. Please note that each follow up
response may take approximately 2 business days as the support professional
working with you may need further investigation to reach the most efficient
resolution. The offering is not appropriate for situations that require
urgent, real-time or phone-based interactions or complex project analysis
and dump analysis issues. Issues of this nature are best handled working
with a dedicated Microsoft Support Engineer by contacting Microsoft Customer
Support Services (CSS) at
http://msdn.microsoft.com/subscriptions/support/default.aspx.
==================================================
This posting is provided "AS IS" with no warranties, and confers no rights.
Click to expand...
 
Hi Jon,

Thanks for the feedback.

Yes, you may use Assembly.GetCallingAssembly static method to get the
calling assembly reference, then you have to use Reflection to enumerate
the types in the assembly and check which type is of type MainForm. Then
call the static filed on it to get the connection string. This is a late
binding approach. However, I do not recommend this approach, since it will
reduce the modularization of your project, also it has worse performance
and coding difficulties.

Since your class library is in different project from the winform project,
it means that your class library should know nothing about the calling
project. So you'd better take the option #2 as consideration, since it will
not violate the modularization of the class library and has no performance
penalty.

If you still have anything unclear, please feel free to tell me, thanks.

Best regards,
Jeffrey Tan
Microsoft Online Community Support
==================================================
Get notification to my posts through email? Please refer to
http://msdn.microsoft.com/subscriptions/managednewsgroups/default.aspx#notif
ications.

Note: The MSDN Managed Newsgroup support offering is for non-urgent issues
where an initial response from the community or a Microsoft Support
Engineer within 1 business day is acceptable. Please note that each follow
up response may take approximately 2 business days as the support
professional working with you may need further investigation to reach the
most efficient resolution. The offering is not appropriate for situations
that require urgent, real-time or phone-based interactions or complex
project analysis and dump analysis issues. Issues of this nature are best
handled working with a dedicated Microsoft Support Engineer by contacting
Microsoft Customer Support Services (CSS) at
http://msdn.microsoft.com/subscriptions/support/default.aspx.
==================================================
This posting is provided "AS IS" with no warranties, and confers no rights.
 
Back
Top