Sitefinty
Manager Class
Introduction
Those C# developers coming to Sitefinity will often use the 'using' keyword to effectively use and dispose of objects. I do this as well but in Sitefinity there is one time when it may seem like the right idea to use it when in fact it is not.
I ran across this tip a while back from Sitefinity Steve and I was reminded of the fact the other day when I was searching Google for an answer and looking at an old project.
Don't wrap your managers in using statements.
using (NewsManager newsManager = NewsManager.GetManager()) { //Code }
This will work but the using statement will dispose of the NewsManager instance at the end of the statement. This still sounds OK until we understand where the instance comes from.
You may at first think, (and I know I did), that the .GetManager() method is a singleton implementation of the object. That there is actually only one instance which is reused. This is incorrect. An instance of the object is retrieved from the Sitefinity Unity container, (DI container) and has a lifetime associated with the HTTP request. Within this HTTP request it is reused. This knowledge may help you understand and explains how when you call .Save() that it saves everything you have done previously.
Sitefinity have used the provider model pattern or also known as the repository pattern. There is still a created instance and it has its own constructors and of course dispose implementations built inside of it that care of all that for us.
How to look at it, is this
You have a custom news widget and on your page you have multiple news feeds and so have your custom widget added multiple times. If you wrap your news manager in a using statement then it will be disposed of and recreated for each widget on that page for that HTTP request. If you don't wrap them then that news manager will be reused. True, you won't see a major impact if you do this. The process is not considered expensive but it is more efficient not to manually dispose of the instance but rather let Sitefinity do it for you.
This came to my attention again because I came across this code in my project.
using (new ElevatedModeRegion(dynamicManager)) { //code }
I used this code to allow anonymous uses to create items in a module. (I could have altered permissions of the module but that is another topic). It is the same as setting, SuppressSecuirtyChecks = true. But by using this I can avoid having to explicitly set it back to false. I haven't got confirmation but I am sure that this does not also dispose of our manager at the end as the first example does.
But I did get to thinking about this property.
Consider Your Security
If you are just setting the property I am sure you are also manually setting it back to false at the end. But are you ensuring that it is set back? What if an exception is raised? You could be leaving your application with a security issue because as we now know, the life time of the manager is the HTTP request. Until the request is over, your manager may not run any further security checks.
Easy to fix though, just ensure you add a finally statement and set the property back to false.
try { dynamicModuleManager.Provider.SuppressSecurityChecks = true; } //optional catch - You could of course set it here as well catch (Exception ex) { //exception handling here //dynamicModuleManager.Provider.SuppressSecurityChecks = true; } finally { dynamicModuleManager.Provider.SuppressSecurityChecks = false; }
Just some things to keep in mind when working with Sitefinity managers.
Thanks for reading and feel free to comment - Darrin Robertson
If I was really helpful and you would buy me a coffee if you could, yay! You can.
Leave a comment Load more commentsMake a Comment