Deliver superior customer experiences with an AI-driven platform for creating and deploying cognitive chatbots
Deliver Awesome UI with the most complete toolboxes for .NET, Web and Mobile development
Automate UI, load and performance testing for web, desktop and mobile
A complete cloud platform for an app or your entire digital business
Detect and predict anomalies by automating machine learning to achieve higher asset uptime and maximized yield
Automate decision processes with a no-code business rules engine
Optimize data integration with high-performance connectivity
Connect to any cloud or on-premises data source using a standard interface
Build engaging multi-channel web and digital experiences with intuitive web content management
Personalize and optimize the customer experience across digital touchpoints
Build, protect and deploy apps across any platform and mobile device
Rapidly develop, manage and deploy business apps, delivered as SaaS in the cloud
The content you're reading is getting on in years
This post is on the older side and its content may be out of date.
Be sure to visit our blogs homepage for our latest news, updates and information.
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.
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.
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.
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.
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.
// 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.
View all posts from The Progress Team on the Progress blog. Connect with us about all things application development and deployment, data integration and digital business.
Copyright © 2018 Progress Software Corporation and/or its subsidiaries or affiliates.
All Rights Reserved.
Progress, Telerik, and certain product names used herein are trademarks or registered trademarks of Progress Software Corporation and/or one of its subsidiaries or affiliates in the U.S. and/or other countries. See Trademarks for appropriate markings.