Sitecore Architecture Best Practices – Part 3: Creating Sitecore Proof of Concept Projects
Very frequently we run into situations when we need to create a proof of concept application to test certain assumptions. These proof of concept projects are for the most part very quick and simple projects that test a theory or provide a concept for the future implementation. The following article describes the Proof of Concept (PoC) pattern for creating these types of quick and simple projects.
If you’ve ever been through the full project discovery and sat through the discovery meetings, there is a good chance that you’ve been asked questions like “can we do this?” or “will this work?”. The knee-jerk answer is of course “Anything is possible with enough time and resources”, however, constraints like time and resources kick in next and this makes all the difference.
Let’s use a hypothetical scenario of building functionality that would need to process a large amount of information for the page load. The page load performance requirement states that all pages must load under two seconds with no exceptions, otherwise, the almighty Google would smack it with a loser stamp. At this point we are being asked whether something like that is possible with a particular set of resources, and since there is no accurate model that we can use to answer that question everytime, we play the “need for PoC” card. Now we are tasked with creating a quick PoC that would do just that one thing and do it really well, to make sure it satisfies the performance requirements.
What are Sitecore PoC projects?
Before we dive into the details of setting up a PoC project, let’s first talk about what these projects are and what they are not.
PoC projects ARE:
- Single purpose
- Small
- Portable
- Partially Reusable
PoC Projects ARE NOT:
- Complete applications
- Messy broken pieces of code
- Churn and burn
- Robust
Single Purpose
Yes. It is very important to stay focused with PoCs. With quick and small ones, it’s very easy, however, there is a basket of scope creeps waiting for developers when these PoC projects get a bit more complex. Should I use dependency injection? Should I use this as an opportunity to learn new technology? Should I make sure it looks good?
Don’t get me wrong, perhaps, the right answer to these questions is yes in your case; however, make sure that whatever you decide to include in any PoC project gets you closer to achieving its purpose, not away from it.
Small
PoC projects should be small. If you are looking at a multi-project PoC solution – it is no longer a PoC. Following the rule of a Single Purpose should help keep it small and focused, however, I would take it a step further and say that PoC projects should not be concerned with maintenance overhead. I think for the first few years of development I’ve been building PoC projects when I thought I was building real apps, as they had very little concern for maintenance 🙂
Portable
In certain cases the platform where the PoC will be tested in unknown, so keep it flexible and throw it into a portable library. With Sitecore projects it’s usually something similar to a web app, however, keep an open mind and think outside the box. Even if the final application that the functionality is intended to live in is a web app, but it’s easier to create a simple console app for a PoC – use the latter.
Partially Reusable
This one is somewhat of a can of worms. Yes, we want something quick and simple, yet we don’t want to waste our time on building something and then later completely rebuilding it from scratch. It’s a catch 22, you can have simple and quick, but not fully reusable; you can have a fully portable production-ready and reusable library, but it likely won’t be quick and simple. The answer lays somewhere in the middle. It’s a cost to benefit ratio – effort vs reusability. In my experience, PoCs tend to be reused more frequently than trashed, thus, I prefer to prioritize reusability with the minimal amount of effort.
The rule of thumb I follow is that the code should be just as clean, as if I were writing it for a real application, however, limited in its concerns. For instance, I avoid using dependency injection, avoid using interfaces, validation, error handling, messaging, proper styling for UI. My PoC apps only work when all of the stars align, just like my senior university project 🙂 However, although the code is not ready for production, it is clean and follows proper separation of concerns and single responsibility principles, which allows me to easily reuse this code in the real application later; simply copy paste the classes, extract interfaces, hook in DI, aspects for validation, logging, debugging and with very little, if any, refactoring – off we go.
Creating a good PoC comes with experience. The key is writing clean and readable code that follows separation of concerns and single responsibility basics principles.
The breakdown of what PoC projects are indirectly explains the points about what they are not. We never want to fall into a trap of turning a PoC project into a real application. The simple reason behind that is that the goals of the two are different, thus, the architecture and patterns used in each must be different. If you find yourself thinking “well, my PoC can just be renamed into the app”, unless your app just does that one thing that the PoC was testing, you are not properly evaluating the solution design.
Source control your PoCs and don’t let it become the playground with spaghetti code, broken methods, unfinished or worse – broken functionality. Do not leave piles of ghost code behind and follow proper code hygiene. Remember that coding is an art of writing code understood by machines and read by humans (while the first part is a given, the second part is often dismissed).Thinking of PoCs as partially reusable projects will also keep avoid falling into the trap of messy code or treating them as “churn and burn” solutions. Finally, if your PoC is robust – it’s not a PoC, it’s a finished product. Robustness goes against the definition of proof of concept.
Choosing the Right Technology for Sitecore PoC Projects
The two most common PoC project types I create are Web and Console Application. Web Application PoCs tend to be more complex, thus, I tend to lean towards console apps for testing theories, however, in our case with a page load concern, we would need to use a web application PoC type.
My web PoCs usually include a single .NET project, with sometimes a Team Development for Sitecore (TDS) project per database. I always start off with a simple web app project and only add TDS when it’s necessary to retain the content state of the PoC.
Sitecore Glass Mapper is the first-class citizen of my PoCs, as it makes working with Sitecore content much easier.
Web Forms. Yep, you read it right. I primarily use the Web Forms framework for its unmatched ability to automate a lot of manual work that comes with developing in MVC. Remember that one of the biggest reasons for using MVC of over Web Forms in web applications is maintenance. When it comes to speed of development, Web Forms blows MVC out of the water. Thus, since we are not concerned with maintenance in PoCs, Web Forms becomes our framework of choice.
NOTE: be careful to avoid falling in the trap of putting business logic in code-behind files, which reduces reusability.
Now that we are onboard with the general idea, let’s get our hand dirty.
How to Setup a PoC Project for Sitecore
The solution consists of just a single WebForms project that is created outside of the Sitecore root folder (we never want to pollute the Sitecore Website folder, especially with quick and dirty PoC left-overs.) Once the project is created, a publishing profile needs to be configured to publish the project to the Website folder pushing the new changes. This can be done by right-clicking on the project file in the Solution Explorer of your favorite IDE in the entire world (Visual Studio) and selecting the Publish option.
If the Sitecore instance is local, which it almost always is for me when I’m building PoCs, I simply choose the Custom Option on the first screen and then I give it some simple name (this bit doesn’t matter, you could call it “bananas” for all you care – have some fun, it’s a PoC!) and on the settings screen, select File System for the Publish Method and point the Target Location field to the root website folder of your Sitecore instance.
To learn more about Visual Studio publishing, check out the How to: Deploy a Web Project Using One-Click Publish in Visual Studio MSDN article.
Once the publishing is configured, we are free to proceed with developing anything our imagination can take us to, just don’t forget to reference the appropriate Sitecore libraries from the \Website\bin and set the Local Copy property to False, to avoid multiple copies of these files flying around.
We can now create Web Form pages and publish them into the website folder. Once published they can be accessed by simply navigating to http://youlocaldomain/mywebform.aspx URL, if the web form page was created in the root of our PoC project. Similarly, we can create an App_Config\Include\BananasPrototype folder in the PoC project and place any patch files in there. We could simplify it by only creating App_Config\Include, however, my Sitecore instances usually host multiple projects and even more PoCs, and keeping configuration files organized is one way of keeping your sanity when dealing with things like that.
Lastly, make sure to remove the web.config file from the root of the PoC project to avoid overwriting Sitecore’s web.config with a publish.
That’s really all that needs to be done to setup a PoC project – quick and easy, takes just a couple of minutes to get going!
Now that we understand the concept behind a Sitecore PoC project and set one up with Web Forms, we can follow the same concept and set one up using a console app, Web API, MVC…etc. depending on the requirements. Have fun with these and cotinue to test and explore! In the next article of the Sitecore Architecture series, we will start getting to the fun part – creating a project solution! Cheers!