It's so easy! Start downloading Enterprise Library 4.1 now while you read this. The data application block syntax has not changed much since the first version. The most notable change was allowing us to use System.Data.Common.DbCommand when version 3.0 was released. I understand the uneasy feeling some developers have using Enterprise Library. My team at my previous employer decided not to use it, thinking it would add increased complexity and would not give us the flexibility we needed if we had to change something. This is typical of groups that do not have an established Data Access Library.
Your Data Access Library should be one of the most highly tested libraries in your application. If there is a problem there, you will have issues everywhere. Enterprise Library not only comes with the source code, but also includes the full suite of unit tests for each of the application blocks. You should feel at ease when you decide to migrate to Enterprise Library. Run it through your full battery of tests before you commit the team to it. If you find any problems, check the forums, request changes/enhancements from the MS Patterns & Practices team, or fix it yourself.
The steps to achieve EntLib goodness:
- Download Enterprise Library
- Add reference to "Enterprise Library Data Access Application Block" and "Enterprise Library Shared Library"
- Change your app.config or web.config
- Write some much more readable data access code
I'll start at step 3 as steps 1 and 2 are self-explanatory. Your connection string needs to be in you app's config file, the machine.config file, or in a connectionStrings.config file referenced in those config files. You can start using it just by adding the <configSections> clock and the <dataConfiguration> node. This will allow you to have one default database for all commands you will execute.
<?xml version="1.0" encoding="utf-8"?>
<configuration>
<configSections>
<section name="dataConfiguration" type="Microsoft.Practices.EnterpriseLibrary.Data.Configuration.DatabaseSettings, Microsoft.Practices.EnterpriseLibrary.Data, Version=4.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" />
</configSections>
<dataConfiguration defaultDatabase="Testing" />
<connectionStrings>
<add name="Testing" connectionString="server=Server_Name;database=DB_Name;Integrated Security=true;"
providerName="System.Data.SqlClient" />
</connectionStrings>
</configuration>
By the time you get to step 4, you have all of the infrastructure in place. Painless so far, let's see how steep the learning curve is.
With ADO.NET, you would write:
116 string connectionString = ConfigurationManager.ConnectionStrings["Testing"].ConnectionString;
117 using (SqlConnection con = new SqlConnection(connectionString))
118 using (SqlCommand cmd = new SqlCommand("usp_ErrorLog_Insert", con))
119 {
120 cmd.CommandType = System.Data.CommandType.StoredProcedure;
121 cmd.Parameters.AddWithValue("Message", "Testing 1");
122 cmd.Parameters.AddWithValue("UserID", 5150);
123 try
124 {
125 con.Open();
126 cmd.ExecuteNonQuery();
127 }
128 finally
129 {
130 con.Close();
131 }
132 }
With Enterprise Library, you write:
170 Database db = DatabaseFactory.CreateDatabase();
171 DbCommand cmd = db.GetStoredProcCommand("usp_ErrorLog_Insert");
172 db.AddInParameter(cmd, "Message", System.Data.DbType.String, "Testing 1");
173 db.AddInParameter(cmd, "UserID", System.Data.DbType.Int32, 5150);
174 db.ExecuteNonQuery(cmd);
Line 170 creates the database object. This is the hardest thing to get used to. You call everything related to the Database object. In ADO.NET, we are used to creating a connection, adding the connection to a command, using the command in an adapter. Here you'll always be using the Database object to create a command, add parameters to the command, execute the command, fill a DataSet, etc. It is definitely less code to write, but it is also more readable and elegant.
If you have a database to execute commands against other than the defaultDatabase specified in the config file, then the first line changes to:
170 Database db = DatabaseFactory.CreateDatabase("OtherConnectionStringKey");
That's it. The patterns & practices team has really done a nice job making it painless to use Enterprise Library. Take the time to try it out again if you reviewed a previous version. I reviewed 2.0, and chose not to use it. When 3.0 came out, I was hooked.