There’s a massive amount of information regarding Mongo in production. The topic can get quite complex in a short space of time too, so I’ve attempted to distil some of it down into a manageable chunk. Whenever we think of moving to production we think of user security, network security, capacity or resource usage and allowing the system to scale. There are other topics too but this is a good place to start as the rest can be specific to each environment you’re working in.
Most of my posts are directly Sitecore related, but this is a subject I would like to cover briefly. I have long been explaining to people that the only IoC container I have every had a REAL issue with when doing performance analysis on sites is ….. NINJECT.
During my time as a dev I have seen many a X vs Y vs Z posts, one such post was IoC Battle and then subsequently IoC Battle revisited. These posts were great, but are somewhat outdated… Things have moved on… So I thought I would take the time to post what this test is like in 2015. I updated the tests to VS2013, .net 4.5.1 and used the latest and greatest nuget packages for the appropriate container.
I also behaviour flattened Windsor since it’s (now) default behaviour for transient resolves is for container to release them, not the GC. And so… ON TO THE RESULTS!
A while back I covered off How to resolve Sitecore commands & pipelines from IoC. This I have used to great effect, to the point I can’t remember the last time I wrote a pipeline entry with a parameter-less constructor. This in itself has aided Unit Testing of pipelines so much I would consider it a must for all Sitecore development.
Recently however, I was faced with an instance where I now had to resolve two near identical items from my IoC container. In a regular .net application, I would simply use the named component functionality of the container and resolve at least one of my instances using such a name. In the case of Sitecore though – I didn’t have any more parameters to play with, and I mistakenly thought I only had the type name.
On closer investigation (and re-reading my own blog post) I noticed that it is simply an identifier NOT a fully qualified reference, meaning I could stuff in whatever I liked – down goes the shed door and cue the music…..
As Glass Mapper for Sitecore rolls over 17,500 downloads on nuget, I thought I would go for this one. I like to try and keep up with what Glass Mapper is doing, particularly on the Sitecore side. So here are a few of the key points / features that I have been introduced to recently.
This should be a nice quick post, but when I look back, it’s something I have done on every project I have used Glass Mapper on.
Glass’ out of the box Castle Windsor implementation tends to create it’s own IWindsorContainer during Sitecore’s initialise pipeline (formerly done using WebActivator). This is great if you want to get up and running quickly, but in my case – especially with the new Delegate mapping function available, I often find that I would rather have a more global container than this, since – for example, some of the delegate mapping does use dependencies from my codebase.
In this post I will quickly describe how to use an external Castle Windsor container with Glass Mapper. If you want to find out more on using other IoC containers including Autofac, StructureMap or Unity as the container for Glass, please take a look at Glass Mapper On Agnostic IoC
Today I’ve been setting up Sitecore and Solr using the instructions found on the SDN. When generating the schema file, you might get an error like the following:
unknown field ‘_uniqueid’
This is when you load the core admin screen to check that the default core ‘itembuckets’ has been loaded correctly. If you read the comments in the generated file it
will tell you that this value should be set to ‘id’. Like so:
I’ve not done any Solr setup in quite a while so I’m still testing the installation. Hopefully this is correct and will save someone some time!
It feels like a long time ago when we first started this series and it has been a fantastic journey thus far. This series has really taken me back to basics in considering the decisions we make on Sitecore projects and what the medium to long term impact of those decisions is.
I thought therefore I would cover a real-life use case of an issue that incorporates some of these posts and show what advantages they have given me and on occasion, why it is that I would have cornered myself had a chosen another route. The project in question has taken a few experienced developers around 11 months to develop and has grown semi-organically based on the requirements from the users.
I would prefix this post with saying – no solution is perfect, neither ours nor any other solution I have seen thus far in my development career. As you will see, myself and the wider team have made mistakes along the way, but it has been the ability to change those decisions that has been key.
This actually should be a fairly quick post, but one that I have seen a few times over now. It is simply a quick answer to the following question – ‘how can I get a POCO (object) given the Sitecore item?’. Before you question too much, I will also explain why the answer is (mostly) not GlassCast(this Item item). This question crops up reasonably regularly, especially given the number of pipelines / commands where we are presented with the item as an argument. There are actually a few considerations when looking at this question and some better and worse ways of achieving this. This post covers many of the common mistakes I have seen when using Glass Mapper in my implementations.
Following on from Strategies to optimise Sitecore MVC Performance. I thought I would write an update to continue and show where I have got to with my quest to optimise the performance of our Sitecore MVC implementation.
Since my previous post, Sitecore have acknowledged some of my findings, and provided a couple of potential fixes for us to try out. On first investigation – these look promising (though my tests are ongoing). I also started to consider alternative methods of setting up parameters, data sources, caching following on from my findings.