by Keyvan Nayyeri via Keyvan Nayyeri on 5/30/2008 4:30:17 PM
In the first and second parts of this post about building a provider model from the scratch, I talked about some main steps of the process. In the first part I talked about main classes in the provider model as well as the configuration system and in the second part I talked about the abstract part of the model.
Now in the third and last part of this series I want to finish the discussion by giving some details about the latest steps of the process including the implementation of the abstract layer, configuring the provider model and finally using it.
One of the obvious steps of building the provider model is implementing the abstract layer based on your own requirements and logic. I talked about the abstract layer in the last part of this series and now I want to implement it.
As you can guess, this implementation is nothing but deriving from the abstract base class that you created for your abstraction.
There is nothing special for this inheritance except that you need to consider the constructor that you had defined for your provider when implementing this class. So for my example, I need to have a public constructor with two parameters. First one is the connection string and second one is a NameValueCollection of my custom attributes. Here and for simplicity, I don't care about the custom attributes but you can retrieve your attributes from the collection via the constructor.
Regarding this stuff, here is the final implementation of my provider based on SQL Server as the data storage.
using System;
using System.Data;
using System.Configuration;
using System.Linq;
using System.Web;
using System.Web.Security;
using System.Web.UI;
using System.Web.UI.HtmlControls;
using System.Web.UI.WebControls;
using System.Web.UI.WebControls.WebParts;
using System.Xml.Linq;
using System.Collections.Specialized;
using System.Data.SqlClient;
namespace ProviderModelSample.Code
{
public class SampleSqlDataProvider : SampleDataProvider
#region Fields
private string _connectionString = string.Empty;
private NameValueCollection _attributes = new NameValueCollection();
#endregion
#region Constructors
public SampleSqlDataProvider(string connectionString, NameValueCollection attributes)
this._connectionString = connectionString;
this._attributes = attributes;
}
#region Implementation
public override void AddItem(int number)
using (SqlConnection connection = new SqlConnection(this._connectionString))
using (SqlCommand command = new SqlCommand("AddItem", connection))
command.CommandType = CommandType.StoredProcedure;
command.Parameters.AddWithValue("@Number", number);
try
connection.Open();
command.ExecuteNonQuery();
connection.Close();
catch (DataException ex)
// Handle the exception
throw ex;
catch (Exception ex)
My database has a single table called SampleTable with ID and Number columns. I used an AddItem stored procedure to add new items to this table.
CREATE PROCEDURE dbo.AddItem
(
@Number int
)
AS
INSERT INTO SampleTable
(Number)
VALUES
(@Number)
RETURN
Now it's time to configure the model based on the configuration system that I described in the first part of the series. This is also very easy and simple. I think that seeing the code is the only thing that you need.
<?xml version="1.0"?>
<Sample>
<Providers>
<add name="SampleDataProvider" type="ProviderModelSample.Code.SampleSqlDataProvider, ProviderModelSample" />
</Providers>
</Sample>
Now you see the similarities between this and what you have in built-in .NET providers.
And the last step is to use this provider model. This is also pretty easy. I create a sample ASP.NET page to use the only method in my provider in order to add a number to the database.
protected void btnAdd_Click(object sender, EventArgs e)
SampleDataProvider provider = SampleDataProvider.Instance();
provider.AddItem(int.Parse(this.txtNumber.Text));
this.lblResult.Text = "Number Added.";
You see that this is very short and simple. Just create an instance of the abstract class by calling its Instance method and then use its base methods!
Now it's the end of this short post series. I received some feedbacks from readers regarding the usage of built-in .NET classes to achieve same goals. As I stated at the start point and is obvious from the title, this wasn't my goal and I had talked about it in my DotNetSlackers article in enough details. My goal was to build everything from the scratch. This is what many enterprise solutions are doing to achieve a better level of flexibility and reliability. Moreover, knowing these steps, you're able to build a provider model for all versions of the .NET Framework.
You can download a package that contains the full source code sample of this post series and start discovering the code.
Original Post: How to Build Your Very Own Provider Model - Part 3
The content of the postings is owned by the respective author. CSharpFeeds is not responsible for the contents of the postings. This site is automatically generated and cannot be reviewed for abusive content. If you find abusive content on CSharpFeeds, please contact us. Designated trademarks and brands are the property of their respective owners. All rights reserved.