The constructor ‘work done’ dilemma

In a recent Glass release I was working on an issue that led to Mike making a comment on how I work as a programmer. The particular issue in question was actually quite straight forward to solve – I wrote unit tests that showed the issue, wrote some sandbox tests that showed how code behaved in the underlying Sitecore library, then fixed the tests approriately. All typical of TDD. The normal thing for me though is then to write a unit test that performs this simple fix 1,000,000 times emitting the result of stopwatch timings at various points. Mike jokingly commented at the time that this was ‘typical Nat’ which, to be fair, he was right on.

In this post I will look at the effect on work done in the constructor and how it has affects your development life in the context of modern DI practice – in particular – the DI principle.

Continue reading

Advertisements

Sitecore WebAPI – Setting up IOC

I’ve had the opportunity to tinker in the depths of the WebAPI in Sitecore 7.5 and 8 recently. I’ll put up a post about setting up controllers easily shortly but until then I thought I’d share how to setup IOC.

In a normal WebAPI environment, we can create our resolver and attach it to the GlobalConfiguration. However, we must remember that Sitecore uses its own pipelines for MVC and WebAPI and so setting this up in the Global ASAX won’t work.

The way I’ve done it is to change the registered WebAPI initialiser class in the Sitecore.Services.Config file found in App_Config/Include. This lets me hook directly into the entry point for Sitecore related WebAPI and adjust the configuration accordingly.

Continue reading

IoC Container Performance – The impact on Sitecore

In recent months I have been very busy working on the performance of Sitecore installations, this has included things like:

Traditionally it has been my opinion that (unless you use Ninject), the IoC container you choose would have little impact to your final solution. In traditional .net solutions, this TENDS to be the case; Indeed when using Sitecore with webforms, the impact TENDS to be less important, which means you are free to choose the IoC container based upon the feature set it provides (on webforms, property injection is a major nice to have for example).

During my Sitecore journey, my improving knowledge of Sitecore led me to better solutions around making the most of my IoC containers. This has led to things like resolve your Sitecore controllers from your IoC container, resolving configuration entries (pipeline) from your IoC container. I utilise these to great effect with Sitecore’s pipelines in particular, bringing various entries in using my container.

This has of course increased the level which the IoC container is relied upon, and in particular if you are using these techniques in the mvc.getModel, mvc.renderRendering or httpRequestBegin, this can easily result in a lot of leverage on your container.

Continue reading

Resolving Sitecore Controllers From Your IoC Container

EDIT: This post covers versions pre Sitecore 8.1.

In this post I will be describing pulling your controllers for use in controller renderings from an IoC container, in this case (again) Castle Windsor. The principle would apply to most containers in the same manner.

In my on-going quest to avoid the ‘new’ keyword in my Sitecore implementations, well – in fact more just to delegate the responsibility of dependency management to my IoC container. I remembered that we had pulled together from a few internet sources, a set of classes that allow the instantiation of Controllers from our IoC container. I wish I could credit the internet sources, but sadly as lazy developers, we gladly consumed and dutifully discarded them. I would also like to add that this was the collaboration of a couple of developers to finalise this solution, so not all my own handiwork on this occasion.

Continue reading

Agnostic IoC De-branded

A quick morning post for any users of Agnostic IoC and anyone thinking about it.

If you have used it, you will have noticed that the binaries and namespaces referred to ‘Cardinal.IoC’. This was a decision made a long time ago, as the original idea for this project was to be part of a bigger ecosystem.

I took the decision well over a month ago that Agnostic IoC was to be de-branded and (due to large work commitments, house move and just life) I have finally managed to achieve this.

For existing users – this will mean that instead of ‘Cardinal.IoC’, it will now be ‘Agnostic.IoC’ at the start of the namespaces.

I think this is a great little utility library and hopefully it will continue to grow with you guys’ support.

Please do contact me with feedback, questions or general abuse 😀

Nat.

Glass Mapper – Agnostic IoC Source

Just a very quick post

This evening I released the source for Glass Mapper running on Agnostic IoC in a more useable format.

You can find it here

https://github.com/cardinal252/Glass.Mapper.AgnosticIoC

This is a great opportunity to get to grips with how Agnostic IoC can be used (especially with Sitecore) to give your modules the flexibility you desire them to have.

Please do feedback on your experience.

Nat

Life Through A Lens – Unit Testing your .net code using Glass Mapper

So now I have gotten my first couple of Sitecore User Group presentations out of the way – I thought I would actually continue on my journey of showing how I use Glass Mapper on the Sitecore platform in real world application.

As you will see from other posts I write – I am very much a TDD advocate. I find it helps focus my mind much better than simply writing code ad-hoc. Also – I hate testing, but love coding – so what better way to get my testing done than coding.

In choosing an ORM, I believe this should be one of your primary criteria since you are going to take some sort of performance hit with it being in the way and for me, trying to justify as just being ‘prettier’ code doesn’t really cut it when you are presenting it to a wider team.

With this in mind, I thought I would kinda tie these two together and look at how I use Glass to perform unit testing on *MY* code.

Continue reading

Life Through A Lens – Component Parts

So – following on the first part in my series on how I have been using Glass Mapper for Sitecore in the real world.

Glass Mapper
Just a couple of quick notes on Glass Mapper, the Glass Mapper developers have done a great job of writing tutorials on most aspects of Glass, and I expect with recent developments on the project, this will only get better, so please check them out at www.glass.lu.

Firstly – Whilst Glass supports using classes for mapping, I almost always use interfaces to represent my model objects, this is due to their multiple inheritance structure and it allowing better representation of the templates on which they are to be based.

Secondly – I almost always use the fluent configuration API – however… I almost always choose to configure this using my Glass Mapper Maps project (described below)

Finally – I like to turn the Automapping feature off for the most part, this is probably because I am a control freak :D.

Glass Mapper Maps
I have been in many discussions with the developers at Glass and I am hoping that this is one of the improvements that they will consider rolling into the product as a whole. Whether this is the case or not – here is what they are and how I use them.

Glass Mapper Maps are a neat solution to isolating the domain objects for use with Glass Mapper. Generally in practice, I start off by creating 2 projects in Visual Studio, these are:

  • xxx.Model
  • xxx.Model.Mapping

In xxx.Model, I would add my regular domain objects – so, ISitecoreItem, ITitleAndIntro : ISitecoreItem, IMetaData : ISitecoreItem

Agnostic IoC
Agnostic IoC is an abstraction layer to allow modules to utilise an unknown final IoC framework, this means that I can perform my registrations and resolves against Agnostic IoC and it in turn performs them against the container of choice. It does this by means of Nuget Packages.

With Glass Mapper, this means that I can use Glass with multiple clients complying with their restrictions of IoC container – be it Autofac, Unity, NInject, StructureMap or pretty much anything else. It also has the upshot of including it in the project, so any module development I choose can also be portable.

So now when I install Glass I need at least the following Nuget Packages

  • Glass.Mapper
  • Glass.Mapper.Sc
  • Agnostic.IoC

Wherever you actually want to perform the initialisation for Glass you also need to include the ‘Translator’ package, so for example – Agnostic.IoC.Autofac. You do not need this in any projects that are not performing the initialisation.

For a more in depth description, please visit Agnostic IoC

Conclusion

In the next post I will be looking at getting Glass Mapper up and running in your solution fully.

May I also draw your attention to the fact that the Glass Development team will shortly be offering training and consultancy on their products which I would highly recommend if you get the opportunity.