Provider model design pattern

My older post about this title was published here. In this post, I’ll try to share my interest in some of the design patterns that were presented in one of the mkdot.net sessions.

Provider model design pattern

Maybe I’m a little late with this post but I want to emphasize the use of the provider model introduced in ASP.NET 2.0 and its implementations within Membership, Roles, Sitemap, and other providers. The starting point for teaching yourself about Provider Toolkit is here and also additional information about building your provider model.
In this post, I’ll show my homework implementing a small Membership provider following the steps described here and here.
 
A provider is a software module that provides a uniform interface between a service and a data source. Providers abstract physical storage media, in much the same way that device drivers abstract physical hardware devices. Because virtually all ASP.NET 2.0 state-management services are provider-based, storing session state or membership state in an Oracle database rather than a Microsoft SQL Server database is as simple as plugging in Oracle session state and membership providers. Code outside the provider layer needn't be modified, and a simple configuration change, accomplished declaratively through Web.config, connects the relevant services to the Oracle providers.

My Homework

First of all setting the web.config sections as described in the picture below is needed. We define a section group name (green rectangle), then define section name (blue rectangle) and type. Then these section definitions need to be included in the <system.web> section.

In the next figure is presented the class diagram of the MyProvider class library. As you can see there are several classes with certain behavior

Class explanation:

1. ProviderBase.cs –  is the base class common to all providers.
2. MembershipProvider.cs – is base class (contract), which is used to implement the desired behaviors for the Membership API.
3. SqlMembershipProvider.cs – is our implementation of the Membership APIs for a Microsoft SQL Server database. Also we can implement it for Oracle or MySQL database systems or it can be implemented with XML or flat files. All of our Data Access Layer (DAL) and Business Logic Layer (BLL) code is put into this class.
4. Membership.cs – is class that defines routines for our API such as CreateUser, Validate, GetAllUsers, IsActive etc. When calling routines on this class internally it will always forward those calls to an instance of the MembershipProvider.
5. Provider.cs - is the basic definition of the feature’s provider class. This class contains information about entries in the <providers> section for MembershipVane's configuration section.
6. MembershipConfigurationHandler.cs - reads the XML configuration information from the web.config file.

Sources:

http://msdn.microsoft.com/en-us/library/ms972319.aspx
http://msdn.microsoft.com/en-us/library/ms972370.aspx
http://msdn.microsoft.com/en-us/library/aa479030.aspx?ppud=4
http://www.agdstudio.com/DesignPatterns/ProviderModel/ASPNET2.0ProviderModel.pdf

Download:

• ProviderPatternExample.rar
• ProviderPatternExample_2.rar

From Silverlight-2-b2 To Silverlight-2

This is my older post but I wanted to move it here on Blogspot.
Recently I made an update on my dev machine with the SP1 for Visual Studio 2008 and Silverlight-2. I made these steps:

1. Installed Visual Studio 2008 Service Pack 1 from here (it is good to read the IMPORTANT paragraph from this page)
2. I had Expression Blend 2.5 June 2008 Preview which I substituted with Expression Blend 2 and then updated it with the SP1 from here
3. Installed the Microsoft Silverlight Tools for VS2008 SP1(RC1) from here

Before I made the update I had developed and locally hosted the Silverlight-2-Beta application. But after the update when I was trying to browse that application I was getting the blue Silverlight logo that is displayed every time when there is no Silverlight installed. Hmm... I was wondering what suppose to be the problem. I've opened the solution and went on debugging. The result was: the application didn't start, it crashed. There were build errors and warnings. After some googling I came to this:

1. Changed the <object> tag from <object data="data:application/x-silverlight," type="application/x-silverlight-2-b2" > to <object data="data:application/x-silverlight-2," type="application/x-silverlight-2" >
2. After step 1 I was getting this error AG_E_RUNTIME_MANAGED_UNKNOWN_ERROR. To resolve this I fixed the references to the vsm namespace (xmlns:vsm="clr-namespace:System.Windows;assembly=System.Windows")  and changed the <vsm:Application.Resources> to <Application.Resources> in my App.xaml file.
3. After step 2 I was getting this error AG_E_PARSER_PROPERTY_NOT_FOUND. To resolve this I "Search and Replace"-ed vsm:Setter to Setter within the entire solution.
4. In my ScrollViewer Style where has been defined TextAlignment and TextWrapping properties, there were XamlParseExceptions and I removed those properties. I found out that ScrollViewer and other ContentControl derived classes have no longer TextXXX properties because of WPF compatibility.
5. I had warnings on the "Foreground" property in the ContentPresenter type. I removed it. Also, I had a compile error on the "Duration" property on Visual Transition, I found out that it has changed to GeneratedDuration.

This solution worked for my problem.
For more detailed information you could read these posts from Mike Snow and Jesse Liberty

Stone Soup Story

Recently I’ve been reading a book about pragmatic programmer,from the journeyman to master, and I wanted to share the story about the Stone Soup. The story goes like this:
The three soldiers returning home from war were hungry. When they saw the village ahead their spirits lifted—they were sure the villagers would give them a meal. But when they got there, they found the doors locked and the windows closed. After many years of war, the villagers were short of food and hoarded what they had.
Undeterred, the soldiers boiled a pot of water and carefully placed three stones into it. The amazed villagers came out to watch.
"This is stone soup," the soldiers explained. "Is that all you put in it?" asked the villagers. "Absolutely—although some say it tastes even better with a few carrots…." A villager ran off, returning in no time with a basket of carrots from his hoard.
A couple of minutes later, the villagers again asked "Is that it?"
"Well," said the soldiers, "a couple of potatoes give it body." Off ran another villager.
Over the next hour, the soldiers listed more ingredients that would enhance the soup: beef, leeks, salt, and herbs. Each time a different villager would run off to raid their personal stores.
Eventually, they had produced a large pot of steaming soup. The soldiers removed the stones, and they sat down with the entire village to enjoy the first square meal any of them had eaten in months.
There are a couple of morals in the stone soup story. The villagers are tricked by the soldiers, who use the villagers' curiosity to get food from them. But more importantly, the soldiers act as a catalyst, bringing the village together so they can jointly produce something that they couldn't have done by themselves—a synergistic result. Eventually, everyone wins.
Every now and then, you might want to emulate the soldiers.
You may be in a situation where you know exactly what needs doing and how to do it. The entire system just appears before your eyes—you know it's right. But ask permission to tackle the whole thing and you'll be met with delays and blank stares. People will form committees, budgets will need approval, and things will get complicated. Everyone will guard their own resources. Sometimes this is called "start-up fatigue."
It's time to bring out the stones. Work out what you can reasonably ask for. Develop it well. Once you've got it, show people, and let them marvel. Then say "of course, it would be better if we added…." Pretend it's not important. Sit back and wait for them to start asking you to add the functionality you originally wanted. People find it easier to join an ongoing success. Show them a glimpse of the future and you'll get them to rally around.
On the other hand, the stone soup story is also about gentle and gradual deception. It's about focusing too tightly. The villagers think about the stones and forget about the rest of the world. We all fall for it, every day. Things just creep up on us.
We've all seen the symptoms. Projects slowly and inexorably get totally out of hand. Most software disasters start out too small to notice, and most project overruns happen a day at a time. Systems drift from their specifications feature by feature, while patch after patch gets added to a piece of code until there's nothing of the original left. It's often the accumulation of small things that breaks morale and teams.
End of story. Also, there are a lot of other interesting stuff to learn or to verify your knowledge from the book, if you have time for reading I recommend it.