January 2005 - Posts
There is probably more interest for this on the web services side, since we rarely do that much direct access to a database. Framework v2.0 makes it really easy to handle transactions. Transactions make it possible to roll back a series of SQL statements, etc when any one of the statements fail.
There are two types of transcations that you will typically deal with Local Implicit and Distributed Implicit (note: there are also Explicit transactions but they seem to be a lot more work and not as convenient.) A Local Implicit transaction is simply a transaction that talks to only one database. A Distributed transaction talks to multiple databases at the same time.
The transactions namespace is smart and will automatically use the appropriate transaction broker based on what type of database you are using. If you are talking to SQL Server 2000 databases, the transactions will be handled through the DTC on the client machine. When SQL Server 2005 is used, the transactions are handled directly by the SQL Server.
Creating a transaction is easy. Simply create a TransactionScope with a using statement and include your code to execute your sql statements. When the transaction is complete, tell the TransactionScope, that the commit is ready by setting the Consistent property to true (Note: this property is replaced by the Complete() method in Beta 2).
Here is an example of a distributed transaction:
using (TransactionScope transactionScope = new TransactionScope())
{
// create a SqlConnection
SqlConnection sqlConnection1 = new SqlConnection(connectionString1);
// create a new sqlCommand
SqlCommand sqlCommand1 = new SqlCommand(someQuery, sqlConnection1);
// open the first connection
SqlConnection1.Open();
// execute the query
SqlConnection1.ExecuteNonQuery();
// close the connection
SqlConnection1.Close();
// open a connection to a second sql server database
// create a SqlConnection
SqlConnection sqlConnection2 = new SqlConnection(connectionString2);
// create a new sqlCommand
SqlCommand sqlCommand2 = new SqlCommand(someQuery, sqlConnection2);
// open the first connection
SqlConnection2.Open();
// execute the query
SqlConnection2.ExecuteNonQuery();
// close the connection
SqlConnection2.Close();
// tell the scope that the transaction is complete
transactionScope.Consitent = true;
}
The basics of transactions are really quite easy now. No longer do you have to worry about using Reflection or deriving from ServiceComponent. This should prove to be quite useful in the future.
I got a new MSDN magazine in yesterday, so there is actually some new content. A while back I talked about expressions in ASP.NET (i.e.: <%$ ConnectionStrings:ReservationsConnectionString %>) and I mentioned that there is a way to create your own. At the time, I didn't know how to do that. According to Marcus that was "Lame!". So now I am following up, and showing you how to implement a custom expression builder.
As an example (straight from MSDN), if you wanted to display the current version of ASP.NET, we can make a custom expression builder like this:
<%$ Version:MajorMinor %>
You can create your custom expression logic by building a new class and inheriting from ExpressionBuilder. In this class you must override the GetCodeExpression method. This method takes multiple parameters. The BoundPropertyEntry parameter contains the text to the right of the colon expression. To access that text you use the Expression property of that parameter.
public class VersionExpressBuilder : ExpressionBuilder
{
public override CodeExpression GetCodeExpression(BoundPropertyEntry entry, object parsedData, ExpressionBuilderContext content)
{
// check to see what the parameter of entry.Expression was
if (entry.Expression == "MajorMinor")
{
return new CodePrimitiveExpression(String.Format("{0}.{1}", Environment.Version.Major, Environment.Version.Minor));
else
{
// add more conditionals here
}
}
}
}
To register the expression builder, add the following section to the web.config.
<compilation>
<expressionBuilders>
<add expressionPrefix="Version" type="VersionExpressionHandler">
</expressionBuilders>
</compilation>
This is obviously a simple example, but you can easily see how we could adopt this to get data from XML files, etc. This could easily replace our custom label controls and things like that.
Ok, well some people have probably already heard about this one, but content has been getting scarce lately. Apparently no one works at Microsoft in the month of December. In C# 2.0, we now have accessor accessibility, which means you can set different levels of protection on the get and set accessors of a property. This is useful, when maybe you want to be able to get the value of the property outside of a class, but only want to be able to set it from within the class.
Here is an example:
// notice the entire property is public, but set is protected
public string Name
{
get
{
return name;
}
protected set
{
name = value;
}
}
No longer is it necessary to add a line such as the following to every single page:
<%@ Register TagPrefix="thrifty" Namespace ="Thrifty.Framework.Web.Navigation" Assembly="Thrifty.Framework" %>
Now you can add your reference to every page on the site by simply adding the following to your web.config or machine.config.
<configuration>
<system.web>
<pages>
<registerTagPrefixes>
<add
tagPrefix="thrifty"
namespace="Thrifty.Framework.Web.Navigation"/>
</registerTagPrefixes>
</pages>
</system.web>
</configuration>
This feature isn't terribly exciting but it will make building pages easier in the future and it will allow easy access to every control we have without having to worry if it is registered.
More Posts
« Previous page