|
dev
newsgroups
|
|||||||||||||||||||||||
|
|||||||||||||||||||||||
Accessing Shared Properties of a Parent Windows App from Class Libmany 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. -- Jon Ebersole Microsoft Certified Solution Developer 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/microsoft.public.vsnet.debugging/browse_thread/thread/d08b27dbd8ffe82e/cf909a3a4963b1e7?lnk=st&q=VB2005+MY+msdn+microsoft+%22Jeffrey+Tan%22&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. -- Show quoteJon Ebersole Microsoft Certified Solution Developer "Jeffrey Tan[MSFT]" wrote: > 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/microsoft.public.vsnet.debugging/browse_thread/thread/d08b27dbd8ffe82e/cf909a3a4963b1e7?lnk=st&q=VB2005+MY+msdn+microsoft+%22Jeffrey+Tan%22&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. > > > 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.  |
|||||||||||||||||||||||
Other interesting topics