Sitecore on .NET 3.5

I can report that using Sitecore with .NET 3.5 and C# 3.0 truly is a seamless transition.

This is especially good news for us developers who tried to upgrade from .NET 1.1 to .NET 2.0.
Back in the day, the transition supposed to be seamless, but surely was not. There was always some strange library containing some braking change, or a project model
who was removed - only to make life difficult for us developers.
This is by my experience NOT the case when upgrading from .NET 2.0 to 3.5.

I have been running a production environment of Sitecore in .NET 3.5 for a couple of weeks now (since we
Microsoft Gold Partners got VS2008) – and there have been no problems so far.
But why is that?


Well:

– There has been no change what so ever in the CLR runtime. It’s still 2.0. This was not the case coming from 1.1 to 2.0. MS had to update the CLR to include generics (parametric polymorphism)

– The C# Compiler has changed, but the target of the compiler remains.

– The library changes are purely additive. Meaning, that things you used in
.NET 2.0 remain the same - and all the new features have been added in new
.dlls, not changing the old ones.

So - Happy coding using C# 3.0 for Sitecore.


To finnish of, lets reflect on the different way to bind children of an Item to a repeater control in Sitecore:


(Wich one do you like the most ?)

//The sitecore way

childrenRepeater.DataSource = Context.Database.SelectItems("/sitecore/content/home/*[@@templatename='DisplayBox']");

//C# 1.0 way, using a standard foreach loop

ArrayList list = new ArrayList();

foreach (Item item in Sitecore.Context.Item.Children) {
if (item.TemplateName == "DisplayBox")
list.Add(item);
}
childrenRepeater.DataSource = list;

//C# 2.0 way, using the iterator pattern (yield statement),and anonomouse delegate

childrenrepeater.DataSource = delegate {

foreach (Item child in Sitecore.Context.Item.Children) {
if (child.TemplateName == "DisplayBox")
yield return child;
}
};

//C# 3.0 way using the query syntax
childrenRepeater.DataSource = from Item child in Sitecore.Context.Item.Children
where child.TemplateName =="DisplayBox"

select child;

childrenRepeater.DataBind();

MailMonitor Sitecore Edition

I have been working on a product called Mail Monitor for years now. It is my pet project and has been for the last 3-4 years or so.

Mail Monitor is an E-mail /SMS campaign tool written in C# hosted on ASP.NET and uses all the cool stuff released from Microsoft within the last years. (Except Silverlight, for now). It is a tool written by a super nerd (me) and is therefore highly extendable using Providers, web-services, Remoting and GoF patterns.

But MailMonitor is not new – but the fact that I made a version for Sitecore is.

For now check out these screenshots.

.NET Remoting Removed from Sitecore

Some time ago I blogged about how Sitecore would include .NET Remoting, a feature that would make Sitecore more scalable and flexible.

Introducing Remoting support was a fundament for creating integration to Sitecore from applications that would not be hosted on the same process as the CMS – a scenario that is very likely in the enterprise. It would also open up the possibility of creating custom tools that could be run from any machine not running Sitecore, even supporting the creation of a Windows Power Shell client.

In essence, the only big different was the all classes in Sitecore.Kernel ultimately would implement MarshallByRefObject something that does not have any impact on the performance of the system, the rest was configuration. It means that supporting .NET Remoting is nearly effortless and free, whereas the benefits are great and powerful.

I just realized, to my great surprise, that none of the classes that used to implement MarshallByRefObject during the Beta period of Sitecore 5.3 still do.
I simply do not understand why Sitecore made this change, and would love to hear their input on this.

Using the ObjectDataSource with Singleton and/or Interface instances

When using Visual Studio 2005 to configure the ObjectDataSource, you will only be presented the option to bind against classes that implement the class System.Web.UI.WebControls.ObjectDataSource. The ObjectDataSource will pr. default create its own instance of your ObjectDataSource class using reflection and use this that instance to retrieve objects that are to be bounded to you data control (for example the GridView).

As a consultant I often see developers having their own data retrieval classes, but when they want to use them in an ObjectDataSource, the class is wrapped in another class implementing the System.Web.UI.WebControls.ObjectDataSource only to satisfy Visual Studio. This leads to twice the complexity – and replication of code. The technique cowered in this blog post might be trivial to some, but I believe that the point cannot be made clear enough.

A better approach is to configure the ObjectDataSource tag to make use of the already present data retrieval class and tell the ObjectDataSource to use exact the instance of you class that you want it to use. This can be necessary if you have decided to only expose interfaces to you client, or if you data access class is implemented as a GoF Singleton or Factory design pattern (thus not letting the ObjectDataSource create an instance of your data retrieval class).

<asp:ObjectDataSource ID="_transactionData" runat="server"
    TypeName="MailMonitorServer.Locator.ITransactionLocator"
    DataObjectTypeName="LinkTrackerServer.ITransaction"
    SelectMethod="Find" 
    OnObjectCreating="ObjectDataSource_ObjectCreating" 
    OnSelecting="ObjectDataSource_Selecting" 
    EnableCaching="false" >
</asp:ObjectDataSource>

This code shows how I use the ITransactionLocator to locate transactions. The thing to notice here is that the ITransactionLocator (TypeName attribute of the ObjectDataSource) is in fact an interface (we cannot create instances of it from the client application) and the only way of getting an instance of this interface is through a Singleton pattern (more about that later).

The DataObjectTypeName defines that the type of the objects that are returned by the ITransactionLocator are of type ITransaction. In order to instruct the ObjectDataSource to use exactly your instance of the ITransactionLocator, and therefore not use reflection to create its own instance, I hook into the OnObjectCreating event.

protected void ObjectDataSource_ObjectCreating(object sender, ObjectDataSourceEventArgs e) {
    e.ObjectInstance = InstanceHelper.Instance.TransactionLocator;
}

Here I assign the singleton instance of my locator class to the arguments ObjectInstance property. This way the ObjectDataSource uses only this instance.

In this case the ITransactionLocator’s Find method needs a special parameter (not covered by the standard <selectparameter> tags. To customize the parameter sent to the Find method I hook into the OnSelecting event.

protected void ObjectDataSource_Selecting(object sender, ObjectDataSourceSelectingEventArgs e) {
    IDealer dealer = (IDealer) Session["dealer"];
    e.InputParameters.Add("account", dealer.Account);
}

In this manner I also have complete control of the parameters that are sent to my ITransactionLocator.

I hope this little code will give you a new idea of now flexible the ObjectDataSource implantation really is.