As many of you know, the extensibility of the Sitefinity product is one of our top concerns. We try to expose everything and make it easily accessible through the Sitefinity API. And by everything, I don’t mean just content, but the whole architecture. We try to provide hooks and events you can subscribe to and plug your custom code into the Sitefinity pipeline. One rule we try to follow is to provide many options for you to do the same thing, and let you decide what is best. Although this makes development easier, sometimes it leads to problems if developers do not fully understand what they are doing. This blog post is going to list 5 practices you should avoid and provide alternatives for them.
Calling ToList() on IQueryable objects
All Sitefinity content is exposed through the provider pattern. When working with collections of items, Sitefinity returns IQueryable objects everywhere. The benefit is that you can use deferred execution for database calls and shift data processing to the database server using LINQ, instead of consuming web server memory and processing power.
Many .NET developers are used to working with IList objects, because of their convenience. This is why, sometimes it’s easy to just convert an IQueryable to IList by calling the ToList() method.
var news = App.WorkWith().NewsItems().Get().ToList();
Although you gain a lot in convenience, you lose all advantages of IQueryable and deferred execution. Never call ToList() on results you got from the Sitefinity API unless you absolutely need to, and know what you are doing. Read Use LINQ deferred execution in the documentation for more information.
Eagerly loading data
Sitefinity is designed to expose the data in the CMS without making assumptions about how you would use it. It’s your job as a developer to understand the usage of this data and only request what you need. Sometimes this is easy to neglect. By default, Sitefinity returns collections that contain all items of a certain type. The scenarios in which you would need all items up front are very rare. Try to use paging and filtering whenever possible to limit the amount of data transferred from the database. If you are only going to display 10 items, don’t request all of them.
Read more about paging and filtering in the Sitefinity documentation.
Implementing custom navigation without the sitemap
Sitefinity comes with a navigation widget by default, which you can use for a lot of scenarios. For one reason or another, a lot of developers decide to implement custom navigation. Maybe they want better control on what is displayed, or want to style the navigation in a way the navigation widget doesn’t support. In these cases, you can expose the site page hierarchy and bind to it.
There are many ways you can do this, and one that comes to mind is to use the Pages API. Don’t go for this first option. The reason it’s a bad idea to use the Page API for navigation is that it only exposes data and doesn’t scale. Navigation is one of those things that are rendered everywhere on your site and calling the API on each request is not exactly a performance best practice. What you can do instead is to bind to the Sitefinity SiteMap provider. This gives you a lot better performance by utilizing caching and lazy loading – it only calls for data when needed. You can get an instance like this:
var provider = SiteMapBase.GetSiteMapProvider(
Once you have the provider, you can bind using the standard ASP.NET way.
Not caching jQuery selector results
You can save some processing by caching the result of the above selector into a variable.
highlightedItems = $(li.highlighted);
For more on this, read the client performance documentation.
Allowing memory leaks in client script controls
// to delete a delegate created in the same component
// to remove an event handler that was added in the same component
More info on disposing client objects is available in the documentation.
These 5 practices are what we’ve most commonly seen in reviewing customer code. You should also follow general development best practices and apply them in your sites. If you have other ideas on what Sitefinity developers should avoid and what they can do better, let us know.