Login | Register   
LinkedIn
Google+
Twitter
RSS Feed
Download our iPhone app
TODAY'S HEADLINES  |   ARTICLE ARCHIVE  |   FORUMS  |   TIP BANK
Browse DevX
Sign up for e-mail newsletters from DevX


advertisement
 

Design for Extensibility : Page 3

Build extensibility and flexibility into your applications to simplify maintenance and accommodate changes.


advertisement
Wrap It in a Factory
As an added bonus, let me show you a really cool way you can wrap all the code that determines what provider to use, instantiates it, casts it, and accesses the interface members into a static (shared) factory class. This is the same pattern that ASP.NET uses with its Membership, Roles, and Profile classes. Describing the Membership class should give you a good feel for what I'm going to do in the application example.

In ASP.NET, you can create a user using the Membership class, using:

Membership.CreateUser( all arguments here...

ASP.NET uses a provider model behind the Membership class in order to determine how it will create a user. When you execute a statement like the one above, you execute the static constructor of the Membership class. At that point, the application reads the app.config and makes the decision as to what provider to use. By the time you call the CreateUser method, the class has a member variable that you've declared as the membership abstraction (in this case, a base class called MembershipProvider) and instantiated as the appropriate provider class as defined in the app.config. The CreateUser method delegates the call to the CreateUser method of said variable, which executes the appropriate implementation. That's what I'm going to do with the provider model.

So here are the steps:

  1. Create a class that will contain static (shared) members only.
  2. Declare a class-level private static variable of type IDataProvider.
  3. In the static constructor, execute the code that will fill the static IDataProvider variable.
  4. Set up static methods that mimic those of the IDataProvider interface.
  5. In each of the methods, call the corresponding method in the IDataProvider variable.
For example, if I called my class AcmeFactory, it would look like this (note that Visual Basic modules behave like C# static classes):

' In VB: Public Module AcmeFactory Sub New() o_Provider = GetDataProvider() End Sub Private o_Provider As IDataProvider = Nothing Public Function GetDataProvider() As _ IDataProvider Dim s_Provider As String = _ ConfigurationManager. _ AppSettings("dataProvider") Dim o As Object = _ Activator.CreateInstance( _ Type.GetType(S_Provider)) o_Provider = DirectCast(o, IDataProvider) Return o_Provider End Function Public Function GetSource() As String Return o_Provider.GetSource() End Function Public Function GetData() As String Dim s_Source As String = o_Provider.GetSource() Dim s_Data As String = _ o_Provider.GetData(s_Source) Return s_Data End Function Public Sub LogData(ByVal data As String) o_Provider.LogData(data) End Sub End Module // In C#: public static class AcmeFactory { static AcmeFactory() { o_Provider = GetDataProvider(); } private static IDataProvider o_Provider = null; public static IDataProvider GetDataProvider() { string s_Provider = ConfigurationManager.AppSettings[ "dataProvider"]; Object o = Activator.CreateInstance( Type.GetType(s_Provider)); o_Provider = o as IDataProvider; return o_Provider; } public static string GetSource() { return o_Provider.GetSource(); } public static string GetData() { string s_Source = o_Provider.GetSource(); string s_Data = o_Provider.GetData(s_Source); return s_Data; } public static void LogData(string data) { o_Provider.LogData(data); } }

Now, to actually use the provider, the client simply has to do the following:



' In VB: Dim s_Data As String = AcmeFactory.GetData() If s_Data <> "" Then AcmeFactory.LogData(s_Data) End If // In C#: string s_Data = AcmeFactory.GetData(); if (s_Data != "") { AcmeFactory.LogData(s_Data); }

Note that the code doesn't even call the GetSource method here; instead, GetData does that for me in the factory class.

You can inject the provider model in many places throughout an application. If you ever find yourself looking at a piece of code and wondering if it may ever be subject to change, think about using this pattern there. If you ever find yourself looking at a process and wondering if it may be one day swapped out, removed, or enhanced, you may want to look at a plug-in model.



Comment and Contribute

 

 

 

 

 


(Maximum characters: 1200). You have 1200 characters left.

 

 

Sitemap