Level: 200
 

Simple information site in Sitecore – part 3: Architecture

WoodenBlock

This is the third part of the article series in 11 parts, describing how to build a simple information site in Sitecore.


In this article we suggest, how you can define your architecture in a Sitecore solution and walk through the architecture for the simple information site we are building. Hope you enjoy the tutorial.

Written by: Jens Mikkelsen
Mon, Nov 23 2009

Articles in this series

 

Part 1: The requirements
Part 2: Installing Sitecore and setting up a Visual Studio solution
Part 3: Architecture
Part 4: The basic layouts

Part 5: Identity and documents
Part 6: Navigation
Part 7: The homepage - content oriented spots
Part 8: The homepage - presentation oriented spots
Part 9: News
Part 10: Search
Part 11: Deploying the solution

 

Introduction

 

There are several ways of designing and implementing Sitecore solutions. This article will use the way we design solutions in Pentia A/S. In Pentia we build medium and large-scale solutions based on Sitecore and have done so ever since the Sitecore product was launched. Through this experience we have defined a component based way of designing solutions, where the goal has been to ensure maintainability, extendibility, readability and reusability in our solutions. We are using this component based approach in all the solutions we develop and have done so with great success.


The design principles are very extensive and could be elaborated more, than what we are going to do in this article. We hope to have a separate article describing how to build enterprise solutions in Sitecore in a foreseeable future, going into detail with all the principles we use in Sitecore. In this article we will focus on the core concepts and the principles needed to implement a simple information site.


Sitecore MVP and Pentia employee Thomas Eldblom has earlier summarized some of the principle on our shared blog Molten Core. You can read the blog post here.

 

 

Component based architecture

 

As mentioned we will design the solution using a component based architecture. The basic idea follows Robert C. Martins (also known as Uncle Bob) ideas of agile software development. You can read more in his book Agile Software Development, Principles, Patterns and Practices. Further I strongly recommend you see this presentation by Uncle Bob about component based design.

 

 

Why use component architecture?

The reason why we use component architecture is maybe best described by talking about why we started using the principles. Before we started building component based solutions, we used the normal layered approach, where the complete project was split into layers such as presentation, business logic, data layer etc. This is a very common approach for software architecture and may work very well on some projects – especially product solutions. However what we found was that it isn’t always such a great idea, when working with agile custom build solutions, which most of our projects are. When basing a website on Sitecore, it will almost always be a custom build solution, which requires further or altered functionality after the first launch.


The problem with a layered architecture for a complete solution was, that when clients had used our solutions in sometime, they came back to us wanting new functionality or changes to existing functionality. As all functionality was packed into the same layer in one big complex solution, it meant that we couldn’t just pull out parts of the functionality and replace it, as it was bundled together. Not knowing what functionality was using special parts of the code, meant that the developers didn’t dare to change existing functionality, as they were afraid what side effects it might have. So due to the agility of the projects and the size and complexity of the solution our projects seemed to become unmaintainable.


Further the developer who needed to change or add some new functionality, needed to know the concepts of the  complete solution, meaning that we often found that projects was depending on one or a few key developers, who had build the solutions.


Last but not least we found that our project method had difficulties to follow the progress in the development face, as everything was interdependent and milestones were difficult to determine.

 

 

So how did the component architecture help us on these issues?

 

Well first we may need to define what a component is:

 

 

A component is an independently group of classes, renderings, templates, database and/or items, which represents a logically grouped set of functionality and is independently deployable.

 

 

As this may indicate, it is no longer the layer or the type of element that is the focus point when grouping – It is the functionality. An example would be that you group all classes and renderings that are associated with news separately from all other classes and presentations (Concrete examples will follow). 

 
Even though you group by functionality and not type, it doesn’t mean you should disregard the concepts in layered architecture. Instead you should practice the layered concepts isolated in each components. So instead of having one layered solution, you will end up with something like this:

 

 

Component layers 

 

 

In this graph you can see how four components stretches over different layers. The Comments component allows visitors to enter comments on an article. It stretches over all layers, as it has its own database and logic up to presentation. The News component only has functionality in the presentation and business logic layer. The reason for this is, that it bases it data or content on whatever is supplied by the index component (as described in this article series on Lucene).

 

In this way you get isolated functionality that can be developed and deployed independently.

 

This has helped solve our problems with custom developed solutions, as functionality is isolated and can be replaced or altered without affecting other components as long as interfaces between them are clearly defined. The components are isolated and hence it is easy for a developer to get an overview of a single component and maintain it. So by using this concept we have gained maintainability, readability and extendibility as components can be added or removed and maintained in isolation.


Further our development methodology is much more in control, as the tasks are divided into separate chunks, where even a non technical project manager can follow the progress on the project.

 

 

Component dependencies

Component interdependencies should be kept at a minimum. There are a lot of principles to follow and idioms that can be used (such as Inversion of Control), but these will not be described in this article. Hopefully they will be more elaborated in the article about architecture on enterprise solutions. For now you just need to know, that they should be kept at a minimum, so your solution will be as agile as possible.


Dependencies arise as soon as you reference logic or similar in another component. In that way it is no longer isolated and the more dependencies you have the more knowledge of the complete projects are needed for the developer to make changes and the harder it is to replace and change existing functionality.
However sometimes it can be a good idea to create base components, which other components depend on. For instance take the Index component from the above example. This can be used not only by the News component, but also by, for instance, a List component, which shows all the latest documents or other items in the solution.


Please note that a dependency is not only due to code references. The reference can also be within Sitecore either by inheriting from a template in another component or by the code referencing a field in a template in another component. So you need to be very aware of such relationships.

 

 

Catch up

So we have gone through the basic concepts of component based architecture and why you should use it. It is important that you have understood what a component is and that the dependencies between them should be well defined and kept to a minimum. For an elaboration I suggest you see the video by Robert C. Martin.

In a way this form of architecture can be compared to a service oriented architecture.

 

 

Component architecture in Sitecore

 

This section will describe the necessary steps and concepts when building solutions in Sitecore using the concepts of component architecture.

 

 

Grouping by function and not by type

The components have an impact on the standard naming and placement in Sitecore. By default files and folders are divided by type and not by functionality. Examples are that renderings are placed in an XSL folder and layouts are placed in a layout folder.


It is important for the readability and architecture in general that components are clearly grouped together. This means that all relevant functionality no matter the type, are placed in the same folder. Therefore we never use the default folders in Pentia, but have created a separate structure that we consistently use on all our projects. You can define your own structure or follow the same structure as we do, which is based on a folder called components, where all the different components reside. For instance the Learn Sitecore solution has the following structure:

 

File structure 

 

Here you can see how all functionality we have, lies in the components folder, where each component has its own folder, where all logic and presentation are placed. To ensure that a component can be deployed independently, each component has its own Visual Studio project and a post build script which copies the .dll files to the bin folder. All other files aren’t copied, but kept in the different component folders.


As the Learn Sitecore project was build in our spare time, there may have been a few rush decisions and the architecture may have a few flaws. For instance the Breadcrumb component probably should have resided in the navigation component and so forth, but you should be able to grasp the idea.


 

 

The Page Type component and interface templates

 

A similar grouping approach is used within Sitecore. Under templates, layouts etc. in Sitecore we have a component folder where each component has its own folder. As dependencies are also created by references to layouts, templates or similar in Sitecore, you may run into problem when defining the templates, which pull out all the layouts and renderings, as these reference all other components. Imagine you have a template for displaying a news article. When defining the layout for this type, you have to reference a lot of different components such as the Navigation component (for the left menu) etc. This is not very good, as you’ll end up with way to many dependencies between the components.


That is why we normally use a component called PageTypes. This component holds all templates that have a visual representation frontend-wise. We call these type of templates Page Types (hence the component name). The component doesn’t define any fields or similar, all it does is inheriting from all the relevant templates and then define the layout. In this way we have one single component pulling together all the strings from all the other components and thereby only that single component is dependent on other components.


This also introduces another concept we use – the interface template. While not holding any presentation in the component itself, the components need to declare a data template which holds the fields needed by the presentation. We call this an interface template. The idea is that the News component needs to define a template which the Page Type component can use, when it declares the news page type. In that way it is sort of an interface defining what fields are needed for it to be a news item.

 

 

The Design component

Besides the Page Types component the Design component is also general and relies on a lot of components. This component holds all styling and general javascript files. It refers styling classes and ids in other components to generate a design for the whole solution. By having this in its own component it can later on be replaced and a complete different skin can be used.

 

 

Breaking requirements into components

 

This section will describe how you can break the requirements up so you end up with a number of components.

 

Identifying the components

The first thing to do when designing the solution is to split up the requirements into components. This is not always an easy task and might change during the project. However you should try and cover most of the requirements. When breaking the requirements into components, you should clearly define the responsibilities and dependencies between them. We normally do this by drawing up a hierarchy and then describing what functionality the component holds.


If we take a look at the requirements specified in part 1, most of the components are pretty obvious:

 

  1. Search component: We need a component to handle everything related to searching on the site.
  2. News component: As news has a lot of functionality, it will require its own component
  3. Index component: As described in this article news will probably require indexing, so we need a component for providing items through Lucene as well.
  4. Navigation component: We need a component to handle all navigation from menus to breadcrumbs.
  5. Corporate identity component: The header, footer etc. holds information about the corporate identity. Further identity such as logos and addresses needs to be changeable – hence we need a component to handle this.
  6. Spot component: (A spot is sort of like a webpart) The spot component should be able to present a variety of different spots. The declaration of all component specific spots – such as the news list spot – shouldn’t be defined here, but in the component where the functionality belongs to. However we will still need to define the generic spots and the page that can present it (for instance the homepage).
  7. Document component: This component is a base component which holds the fields for any content item that should be presented. For instance a title and content field.
  8. Page type component: As described earlier
  9. Design component: As described earlier

 

These are the most immediate components in the project; and I know, that it may seem a bit difficult to identify them the first time you do this, but it will come along when you get more experience with component architecture. When you break your solution into components, you should focus on groups of functionality – such as “search”. These types of components are actually often mentioned in the requirements… As you can see a lot of the components we have identified is mentioned in the list of requirements. When you have identified the most obvious the other components gets easier to identify.

 

 

Component dependencies

Now that we have defined the different components, we need to find out the dependencies between them.
If we start at the top (from a UI perspective) we know that the design and page types component are going to be dependent on all components, which has a presentation. As we talked about earlier, these two components pull together the strings from other components, so they are dependent on all but the Index – which is purely data related.


Further all components which hold a spot will need to know the spot component as the templates will have to inherit from the interface template representing a spot. Right now only the News component have a spot, so it will be dependent on the spot component.


Last but not least the news component will retrieve its data from the index component, so it will be dependent on this as well.


These dependencies give the following hierarchy:


 

Dependencies in components

 

 

I haven’t cheated and developed the site yet, so the dependencies and components may change. This just make the scenario more real and I will of cause update the article, if any changes are needed. :)

 

 

Now that we got the components main purpose described and the dependencies are highlighted, we can now get started with the development. The product of the architecture may seem a bit blurry, but you can decide for yourself, how much you want to go into detail with each component before starting development. As this is just a simple information site, I reckon that we’ll be able to implement from this abstract design.


If you feel a bit uncertain about the principles and you aren’t completely clear on all concepts, don’t worry! I think you’ll get a better idea when we get to the practical implementation.

 

Please rate this article


24 rates / 4,08 avg.

  • About the author:

    Jens Mikkelsen

    Jens Mikkelsen is a partner at Inmento Solutions a Sitecore consulting firm. He works as a Sitecore specialist and consulting helping clients architect and build quality Sitecore solutions using the newest modules and tools. 

    Further he has been deeply envolved in various complex solutions and has built up a strong knowledge of Sitecore architecture and best practices. He has especially focused on and is specialized in debugging and analyzing Sitecore solutions.

     

    Jens is very interested in the technical mechanisms in the new marketing products such as Sitecore DMS and Sitecore ECM.

    My Sitecore Freelance CV

16 responses to "Simple information site in Sitecore – part 3: Architecture"

Hi Jens,

Thanks for the article, this component-based architecture is definitely interesting!

Would it be possible to see more screenshots of the actual file system architecture and also the PageType and interface template architecture within Sitecore?

Also, how does having multiple sites within one Sitecore instance affect the component architecture? How do you separate the components between sites?

Thanks!
Posted: Wednesday, December 02, 2009 2:45 PM
Hej Adam,

Thanks for the feedback. I think a lot of the components will be easier to understand, when we go throgh the actual example. However I will post some screenshots from the LearnSitecore solution later.

Regarding multisite... I find that the component architecture is really great for multisite. By default all components are developed to handle multisites and can thereby be reused on each site.
What I often experience with multisites is, that the each sites have small differences. With component architecture it is very easy to replace one component with another, which makes it much more maintainable.

Hope it makes sense... Otherwise let me know.


Cheers
Jens
Posted: Tuesday, December 08, 2009 10:23 AM
Nice article Jens, do you have an ETA on the next article in the series?

~james
Posted: Thursday, March 11, 2010 6:11 PM
Hi James,

Just back from vacation and I hope to get some time over the next couple of weeks to write some new articles - including the next part in this series.

Cheers
Jens
Posted: Monday, March 15, 2010 10:52 PM
Hi guys,

The forth part is finally here and I hope to write the fifth part in this easter holiday. Yay! Progress! :)

Cheers
Jens
Posted: Wednesday, March 31, 2010 12:55 AM
Hi Jens,

Firstly thank you for the articles you have written so far, it is a great help to see the architecture approach used by other people.

I am trying to follow your approach, but have also looked at the Sitecore starter kit. I was wondering if you could help me understand how the Starter kits Item types, Site Sections and Content templates can be adapted to follow your compoment based architecture? Can these two approaches be merged?

The structure of the Starter kit templates makes sense to me with individually defined site sections and separate content items for those sections, but how should this be broken into components?

Thank you and best regards.
Posted: Monday, January 03, 2011 10:05 PM
Hi James,

To be honest I don't think it is an easy task to convert the starter kit to the component architecture. However you can easily implement a new site with the things you like from the starter kit in the new solution. You are not limiting yourself, when using component architecture.

So in short I think it will be easier to create a new site, than converting the starter kit to the component architecture.

I know this probably doesn't help. :(
Posted: Monday, January 03, 2011 10:14 PM
Hi Jens,

Firstly thank you for the articles you have written so far, it is a great help to see the architecture approach used by other people.

I am trying to follow your approach, but have also looked at the Sitecore starter kit. I was wondering if you could help me understand how the Starter kits Item types, Site Sections and Content templates can be adapted to follow your compoment based architecture? Can these two approaches be merged?

The structure of the Starter kit templates makes sense to me with individually defined site sections and separate content items for those sections, but how should this be broken into components?

Thank you and best regards.
Posted: Monday, January 03, 2011 10:42 PM
Hi Jens,

Firstly thank you for the articles you have written so far, it is a great help to see the architecture approach used by other people.

I am trying to follow your approach, but have also looked at the Sitecore starter kit. I was wondering if you could help me understand how the Starter kits Item types, Site Sections and Content templates can be adapted to follow your compoment based architecture? Can these two approaches be merged?

The structure of the Starter kit templates makes sense to me with individually defined site sections and separate content items for those sections, but how should this be broken into components?

Thank you and best regards.
Posted: Monday, January 03, 2011 10:43 PM
Hi Jens,

Thank you for your quick reply. I am creating a new site. Sorry, maybe I didn't explain myself properly. I like the structure of the templates in the starter kit and want to use that, but with the component architecture should I be creating components for the different sections of the new site? or should components be based on the functionality of the site?

Cheers.
Posted: Monday, January 03, 2011 10:58 PM
Hi James,

You should create components based on functionality. So that if you have a section for news, you should create a news component; if you have a section for calender, you should create a calender component etc.
In these components you should create the data templates, specifying the different fields.

In your page types component you should specify the templates you want the editor to create and then assign layouts to these.

Within the individual component, you can create the templates more or less as you like.

Hope that makes sense.

Cheers
Jens
Posted: Monday, January 03, 2011 11:03 PM
Thanks for yet another excellent article. I find your articles very helpful and informative. The component based architecture is very interesting.

Would it be possible for you to provide 1 or 2 screen dumps for the section: "The Page Type component and interface templates",
so we could see how it looks like inside Sitecore CMS. Basically just like you have done in section "Grouping by function and not by type"

I thinks screen dumps are very good to explain and confirm concepts.

Again thanks a lot for the time your are investing into this.
Posted: Tuesday, February 01, 2011 1:12 PM
Hi Mohammad,

Thanks for your comments. There are more screenshots in the next couple of articles. Further you can download and install the solution I have built, so that you can get an overview of the architecture in practice.

Let me know if that doesn't help you.

Cheers
Jens
Posted: Wednesday, February 02, 2011 12:39 AM
Hi Jens,

Thanks for this brilliant series of articles. I'm busy setting a new soloution and this is a great implementation of component based architecture for sitecore.

I may be nitpicking, but was curious as to why you grouped the PageType project with components. If we're seperating by function, wouldnt it make sense to differentiate the PageType as a Layout not a Components.

Setting up my solution i've got the PageType project within the components folder, but the more I think about it - it really inst a component in fucntion as it hlds all the layouts and so I'm going to seperate it out further into a Layouts project and then post-build deploy to the sitecore layouts folder.

I was hoping to hear your thougts :)

Thanks again for a great article

c
Posted: Friday, May 27, 2011 7:30 AM
Hello Jens,
I just came across this great series in researching how best to best implement Sitecore. I notice this is 5.5 years old now, but I believe the main concepts are relevant today.
Given the time that's past since you published this, and the various enhancements to Sitecore over the years since then, how do you feel this approach work with Sitecore 8 xp?

Amazing work with this, not only explaining "how", but also "why".

Thank you for sharing,
Matt
Posted: Wednesday, May 27, 2015 4:50 PM
It is still very relevant. I have changed very little however I would only go for the presentation oriented spots framework and there might be some trouble with MVC folder structure, if you use MVC. If using MVC I would look into Areas like mentioned here http://jockstothecore.com/sitecore-support-for-mvc-areas/ to keep grouping by functiona and not type.

Cheers
Jens
Posted: Wednesday, May 27, 2015 5:07 PM

Leave a reply


Notify me of follow-up comments via email.
 
 
#nbsp;