Setting a property based on a data value:

In this example, we have a label on a form that will display a dollar amount from our data source.  If the dollar amount is negative we want the label’s background to be red, and green if the value is positive.  To do this, we simply create a converter class in our code behind page.  This will use the numeric value and return a Brush object which we will use in our label’s Background property.  Here’s the code for the converter:

We then have to create a simple reference to our converter class in our ResourceDictionary in the Window.Resources section of our XAML:

So far so good.  Now all we have to do is bind the label’s background property to the converter and data value.  Notice that we have to bind both the label’s content (text) and background to the Amount value from our data context.  We also can set the ContentStringFormat property to automatically format the value as currency:

Setting a property based on another control’s property:

This method is useful when there isn’t a data field to bind to, but there is a need to conditionally set a control’s property.  Let’s assume we need to set a button control’s IsEnabled property based on a check box’s IsChecked property:

As you can see, we’ve bound the IsEnabled property of the buttons to the IsChecked property of  the check box by specifying the ElementName (control’s name) and Path (control’s property).  We also bound the Content property of the button to the same IsChecked property using the same method, to show the current state of the button (which the framework automatically converts from a boolean to a string).  The best part about this method?  No code behind!  Here’s the result:

This is a very simple overview of the power of converters and bindings, and how they can be used to help you do more than just display the data on your page.

First we will need to create a class for the Html Helper, I usually prefer to add a folder to my solution called Helpers. Both the class and the method will need to be static. In addition you will need to add a HtmlHelper parameter to the method that is preceded by the keyword this. This first parameter of the extension method indicates the class that the extension method extends, which in our case would be a input control.


using System;
using System.Web.Mvc;

}
}


Next within our DatePicker Method we will want to add the input control and the Jquery, and I found this easiest way to do this was to use TagBuilders. The TagBuilder Class is a utility that easily allows you to build html tags. We will be using two TagBuilders, one for generating our input box, and a second TagBuilder for the script tag. An overview of the TagBuilder class can be found here. Any script tag will need to be written with the TagBuilders InnerHtml property, or it will be interpreted as text on the page. The resulting code is below:


using System;
using System.Web.Mvc;

var scriptBuilder = new TagBuilder("script");
scriptBuilder.InnerHtml = "$(function() { $('#" + id + "').datepicker();});";
return builder.ToString(TagRenderMode.Normal) + scriptBuilder.ToString(TagRenderMode.Normal);
}
}
}


Next to be able add the control easily on any page we will need to add the Namespace for our Helpers to the web.config file as shown below.


<pages>
<namespaces>
<add namespace="System.Web.Mvc" />
<add namespace="System.Web.Mvc.Ajax" />
<add namespace="System.Web.Mvc.Html" />
<add namespace="System.Web.Routing" />
<add namespace="MvcApplication1.Helpers"/>
</namespaces>
</pages>


Finally we can easily add our DatePicker control anywhere to our site with our new Extension.

Date: <%= Html.DatePicker("myDatePicker") %>


This short tutorial assumes that your site is already set up for using JQuery, and the UI controls. Details for using Jquery can be found here.

Unfortunately this is a step that will need to be reproduced each and every time a database refresh is done. So an approach that worked for us was to create a new EF4 model at runtime, injecting the required code into it.

To do this first you need to create a MetadataWorkspace (System.Data.Entity), which allows you to interact with model metadata.

MetadataWorkspace workspace = new MetadataWorkspace();

Next you will need to read the existing metadata from your current model and replace the text with the change we manually added before. To do this we will query the executing assembly for the Store Schema Definition Language (SSDL) file which is the file we initially had to manually edit.  You can locate the names of your SSDL, MSL, and CSDL in the web.config.

Assembly edmAssembly = Assembly.GetExecutingAssembly();
StreamReader metaReader = new StreamReader(edmAssembly.GetManifestResourceStream("Models.ModelName.ssdl"));
var text = metaReader.ReadToEnd();
text = text.Replace("<Property Name=\"RowGUID\" Type=\"uniqueidentifier\" Nullable=\"false\" />", "<Property Name=\"RowGUID\" Type=\"uniqueidentifier\" Nullable=\"false\"  StoreGeneratedPattern=\"Identity\" />");

Once we have a modified SSDL we can began to build a new EF4 model. This will require the other two components, the Conceptual Schema Definition Language (CSDL) and the Mapping Specification Language (MSL).

The MSL, SSDL, and CSDL did Snoop Dogg Come up with these names?

To get the MSL and CSDL we can just read them in with MemoryStreams (System.IO) like so.

var ms = new MemoryStream(System.Text.Encoding.UTF8.GetBytes(text));
var sReaders = new[] { XmlReader.Create(ms) };
var mReaders = new[] { XmlReader.Create(edmAssembly.GetManifestResourceStream("Models.ModelName.msl")) };

var cReaders = new[] { XmlReader.Create(edmAssembly.GetManifestResourceStream("Models.ModelName.csdl")) };

Now that we have streams of the 3 necessary files we can assemble them into the model. For the SSDL we use a StoreItemCollection (System.Data.Entity) to load the xml file. For the CSDL we use the EdmItemCollection (System.Data.Entity) and then we map those to files to the MSL using the StorageMappingItemCollection (System.Data.Mapping).

var sCollection = new StoreItemCollection(sReaders);
var cCollection = new EdmItemCollection(cReaders);
var csCollection = new StorageMappingItemCollection(cCollection, sCollection, mReaders);

Now that we have our new EF4 model built we simply register it in the MetadataWorkspace.

workspace.RegisterItemCollection(sCollection);
workspace.RegisterItemCollection(csCollection);
workspace.RegisterItemCollection(cCollection);

Finally we declare are data model context with the new workspace and our connection string.

DBModel _db = new DBModel(new EntityConnection(workspace, (SqlConnection) connectionString));

We then have access to a new EF4 model at runtime that now has a GUID that can be an entity key. To be safe we then clean up any loose ends after committing the database changes.

ms.Close();
_db.Dispose();

What I was doing was to use it to write event entries in windows event log as part of the exception handling in an ASP.NET web application.  Nothing fancy.  It worked fine on my PC, but it didn’t write anything to the event log when Logger.Write is executed. No exception was thrown from that line of code either.  The program just went through as if that line of code was skipped.

It turned out to be a permission issue. When I debug the application in Visual Studio, it was running under my windows account credential which had permission to create Event Source in the system.  However, when the application was deployed to the server, it was running under the default account which was “NT Authority\Network Service” in my case.  By default, that account doesn’t have permission to create new Event Source in the system.  It does have permission to write event entries though.  So, when Logger.Write was executed, it couldn’t proceed because the Event Source wasn’t there, and the program didn’t have permission to create one.  Actually, it makes sense to not throw any exception on this line, because people like me usually use this to log exceptions, and if the logging process itself throws exceptions, there is probably nowhere else we can handle and/or log them.

Now, how this can be resolve?  The solution is quite simple.  As long as the Event Source is created ahead of time, it will be no problem.  What I did was to create required Event Source(s) on server through CMD.exe.  Here is a sample command:

eventcreate /ID 1 /L Application /T information /SO "My Event Source" /D "My Event Source is created."

This command will create an event entry in the Application log.  If the Event Source doesn’t exist, it will be created during the process.  This is only required when the application is deployed to the server first time.  So, I usually do it manually on server.  However, if that’s not the case, you can build it into the installation package, and when the application is installed, the Event Source is created as well.  Of course, you can use .NET to create Event Source in your installer too.

In order to get away from code being escalated to MSDTC (Microsoft Distributed Transaction Coordinator), I decided to use single SqlConnection per TransactionScope.  Also, to maximize code reusability, we ended up with the following development pattern.  For simplicity reason, error handling is not added in the example below.

public static void CreateOrder(Order myOrder)
{
    using (TransactionScope scope =
            new TransactionScope(TransactionScopeOption.RequiresNew))
    {
        using (SqlConnection cn = DB.GetConnection())
        {
            cn.Open();
            SqlCommand cmd = new SqlCommand();
            cmd.Connection = cn;

            InsertOrderTransaction(myOrder, cmd);
        }
        scope.Complete();
    }
}

internal static void InsertOrderTransaction(Order myOrder, SqlCommand cmd)
{
    cmd.CommandText = "dbo.spCOrder";
    cmd.CommandType = CommandType.StoredProcedure;

    cmd.Parameters.Clear();
    cmd.Parameters.AddWithValue("@CustomerID", myOrder.CustomerID);
    // ...

    myOrder.ID = Convert.ToInt64(cmd.ExecuteScalar());

    InsertOrderTransactionPostProcessing(myOrder, cmd);
}

As you can see, the method InsertOrderTransaction takes the Order object and a SqlCommand instance. It assumes that the SqlConnection has been established for the SqlCommand in the calling method. It doesn’t care if the SqlCommand needs to be executed within a transaction or not. It simply executes a SQL statement or a Stored Procedure. In its calling method CreateOrder, it defines the TransactionScope and defines and opens a SqlConnection. It can call multiple transactional methods (in this case InsertTransaction) and keep them all in one transaction. However, you don’t have to define a TranscationScope in the calling method if you are not dealing with multiple SQL operations. You can also add pre-processing and post-processing functions if needed.

internal static void InsertOrderTransactionPostProcessing(Order myOrder, SqlCommand cmd)
{
    if (myOrder.OrderItems != null)
    {
        foreach (OrderItem myItem in myOrder.OrderItems)
        {
            myItem.OrderID = myOrder.ID;
            InsertOrderItemTransaction(myItem, cmd);
        }
    }
}

internal static void InsertOrderItemTransaction(OrderItem myItem, SqlCommand cmd)
{
    cmd.CommandText = "dbo.spCOrderItem";
    cmd.CommandType = CommandType.StoredProcedure;

    cmd.Parameters.Clear();
    cmd.Parameters.AddWithValue("@ItemID", myItem.ItemID);
    // ...
    myItem.OrderItemID = Convert.ToInt64(cmd.ExecuteScalar());
}

One thing you have to be aware of is that TransactionScope may not be a good choice if these operations take too long to complete. The reason is obvious. Transaction may result in temporary locking on certain objects (such as tables) in your database. If the transaction needs 5 minutes to complete, it may lock a table for that long and your users may be unable to access data in the table for that long. If anything goes wrong at the very last second in the transaction, it may take another 5 minutes for the database to roll back previous operations in this transaction, and make the table inaccessible to your users for even longer. So in cases like this, one transaction may need to be broken into multiple segments.