Patterns and Origins: Data Provider Model

Modified on 2009/03/19 17:05 by daveburke Categorized as Patterns and Origins, Sueetie Source Code
Tags: no tags for this item
<div class="WikiTop">
The data provider model is common throughout the applications that comprise Sueetie.  Here we'll cover the Sueetie Framework's particular flavor of provider.
</div>

==Sueetie Data Provider - Patterns==


Each of the applications in Sueetie uses a Data Provider, and in most cases several providers to manage data for multiple sources simultaneously.  This is the case with BlogEngine.NET, which uses an XML Provider to manage all blog data and a SQL Provider to manage user data.  BlogEngine.NET is blazingly fast, so besides having a robust provider implementation, and as I mentioned, the raw speed of BE.NET was another reason the Sueetie.Core Data Provider model was patterned after the BE.NET design.

Here is the layout of the Sueetie.Core Class Library and the location of the various Data Provider classes.  Pertinent items include the Base and SQL Provider classes in the Providers folder, the Container objects which are populated by the provider and passed to the application, and the Action Class or Proxy which does the passing.  In our example the class is "SueetieUsers.cs."  All Action Classes are located in the Sueetie.Core root directory.

[image|Sueetie.Core Class library and Provider Elements|http://sueetie.org/x/site/2009/sueetiecore0317.jpg]

Below is the core of the SueetieDataProvider base class and shows how the provider is loaded from the Sueetie.Config file using the [PatternsConfiguration|SueetieConfiguration] class.

[image|Loading the Provider|http://sueetie.org/x/site/2009/SueetieProvider0319.jpg]


The providers are loaded from Sueetie.config in SueetieConfiguration using LINQ-to-XML.  That method is shown below.

{{{{
private void PopulateProviders()
{

    var providers = from provider in configXML.Descendants("Provider")
	select new SueetieProvider
	{
		ConnectionString = (string)provider.Element("connectionString"),
		Name = (string)provider.Element("name"),
		Function = (string)provider.Element("function"),
		ProviderType = (string)provider.Element("type")
	};
	SueetieProviders = providers.ToList();

}
}}}}


Because the Sueetie.Config file is shared across multiple applications, the actual connection string is entered into the .config file.

{BR}
[image|Sueetie.config with Providers defined|http://dbvt.com/x/blog/2009/sueetieconfig0318.jpg]
{BR}{BR}
Here is an example of using the Data Provider in the SueetieUsers.cs Action Class.  We'll create the Provider with LoadProvider() and perform our query.

{{{{
public static void CreateSueetieUser(SueetieUser sueetieUser)
{
	SueetieDataProvider _provider = SueetieDataProvider.LoadProvider();
	_provider.CreateSueetieUser(sueetieUser);
}
}}}}


==Sueetie Data Provider - Origins==


I wanted to pattern the Sueetie.Core Provider model after BlogEngine.NET's as much as possible for performance reasons and simply because I wanted to spend more time in one of my favorite applications.  Main differences in implementation have to do with loading the provider through SueetieConfiguration instead of a web.config ProviderSection and breaking out the Provider code from the Proxy class file.  

For example, BlogEngine.NET uses a BlogService.cs Class as proxy where it also houses the Provider method in loading all providers.  

{{{{
public static Post SelectPost(Guid id)
{
	LoadProviders();
	return _provider.SelectPost(id);
}
}}}}

I separated the provider to make the Sueetie Framework more extensible by supporting multiple proxy classes representing different application components to share a single provider in a separate class.



{s:PatternsTOC}