Blank Sitecore with MVC renderings instead of Webforms

Sitecore has now supported and promoted the use of MVC as the rendering mechanism over Webforms for more than 3 years (probably a lot longer).

I think everyone agrees, that this is a good thing, although I loved creating sites using XSLT back in the days ;) (I might be very alone with this statement though?)

BUT why is the sample layout and renderings, which are part of a blank installation, still using Webforms??

Probably because it is not a big deal and those samples should not be used anyway. But I often use a blank site for a small test or to prove something to a customer/fellow partner or colleague. And it is annoying, that I need to create a new layout to be able to show the new Sitecore Forms in the workings for example.

So I recreated the sample renderings in MVC (only view renderings, so no compilation is needed) and you can download the package here so you don't have to do the same ;)

Download package

//If you find this post informational/misleading/educational/whatever, please provide a comment.

//Also it would be nice with just a HI, so I know real people are actually seeing my posts ;)

My blog moved back ;)

After many years, my blog has now moved back to this platform!

My (limited) contribution since moving the blog to sitecore.net can still be found here: https://community.sitecore.net/technical_blogs/b/sitecore_what39s_new, although the newest is from 2015, so probably a bit out of date.

I will start blogging about Sitecore again here (especially targeted at the not-so-experienced and new-to-the-platform audience), and first up, is about my new mantra and start of a movement #SimplifySitecoreDevelopment.

For a long while now, I have seen Sitecore solutions becoming over-engineered (in my opinion), resulting in a steep learning curve especially for new team members and developers new to Sitecore.

Also, unnecessary time is spent on developing the "perfect" code that (in theory) is easy to extend and adjust over time. What I have experienced is, that the time saved in the long term, rarely justifies the time spent building that perfect dependency-injection enabled, MVVM, service layered, etc. component as the requirement often change so much over time, that the component needs to be completely rebuild anyway. Or even more so the case, the platform is changed to another platform or upgraded to a newer version, where the whole site is redesigned and re-coded anyway! 

Sitecore is an advanced platform, allowing any imaginable customization and you have probably heard the sentence "what you can do in .Net, you can do in Sitecore" many times if you move around the Sitecore community circles! That does not mean it is a complex platform for developers, unless they make it their mission to make it complicated!

And just to make sure I don't get everyone on my neck already, #SimplifySitecoreDevelopment does not mean abandoning the great intentions in the Helix guidelines (https://helix.sitecore.net/). On the contrary, I will make sure to follow those guidelines in the coming blog posts.

Mark Cassidy @cassidydotdk delivered a great talk on this years Sitecore Symposium (a blog post about that event is also in the making ;) on the same topic, so I am not alone in my little movement ;)

First up is a rant about ORM/strongly typed field access vs native Sitecore API:

1. Why not use the Sitecore native API (not online yet)