Manager .NET Group/Software Architect
30. Dezember 2011
Data-Modeling in Sitecore
Apart from top features in Sitecore regarding marketing, design and customization capabilities, one thing makes Sitecore the best ECMS to me: Being a business logic developer and Software Architect, I don´t care that much about the things mentioned above. I’m into Sitecore because of its prospects of Data Modeling. Everything´s about Data Modeling in Sitecore…and to provide websites which ought to last several years, you´d be sure to have a good Data Model!
I like using the Sitecore Content Tree to enable my developers and the authors to reuse items, having reasonable but not oversized references between items and last but not least self-organizing items/data. The most fun part isn´t developing a website with Sitecore, it´s integrating business logic/custom code and customer related stuff (outdated adjacent systems) into the website.
In Sitecore trainings, you learn how to structure your website with Placeholders and different types of presentation components. But beside some content fields, there´s no information regarding the real data, whether or not it´s rendered directly.
Object Orientated Approach
I think the best way to design items/fields is to think of them as objects. Thus, items should carry their own information. This covers data to render, references to data being rendered, fields to configure the behaviour of the item/page. There´s nothing worse than information about an item spread over the content tree or a mix of items and config files – this will definitely lead to nan unmaintainable website and only specialists would be able to configure the site. To get the most out of a website, speaking of reusing information and self-organizing items, it is mandatory to keep this OO approach in mind.
Reuse of information
There are several ways to provide reusable information. Please try to keep this order to keep your project maintainable:
a) Standard Values: Don´t only use them for workflows and presentation, use real values and use item inheritance!
b) If Standard Values aren´t sufficient, source fields out and use referencing types like Multilists. This is a great deal if you want the user to gain options, e.g. to select different footers or different credentials for a synchronization task
c) Have configuration items in a node in your Content Tree – not part of the website hierarchy
d) Develop ItemHandlers doing the magic
We often use c) and d) in combination.
In our projects at netzkern, we have two extra folders within the Content Tree to store those items:
- Configuration (c) )
- Ressources (b) )
Exception to the rule:
Sometimes the OO approach can lead to oversized solutions. We needed to develop a “facet search” for a big chemistry corporation from Germany. In the standard approach, every item would have to carry its information about the facets it belongs to. But when rendering a category list and counting the related items, we discovered the need of caching the results. But then a colleague had the idea of switching references. We then developed a publishing handler and every time the data items are being published, we store the references in the category items as well. So, the rendering is pretty straightforward and fast. Don´t stop thinking the other way around!