Workmate of mine Adam Rambridge sent around an excellent survey on monday asking what best practices we recommend for sitecore projects. Instead of writing up a blog post this week I’ve taken the easy route and just copy/pasted the results ;)

Question Answer
Your name Steve Green

Information architecture
How best to structure templates? Typically I would break the templates down into 3 folders, field sections, page types and meta data.Field sections are reusable collections of fields such as title/text, meta tags, navigation that are inherited by page types.Page type templates are for items that are under the home node, ideally they are the only templates to have presentation values.Meta data templates are for items outside the web context which are typically stored in the global folder. These cover things such as reusable rich text blocks, control labels and configuration, dropdown menu sources and other content that doesn’t ‘belong’ to the content items.
How should the content structure be organised? I’d recommend prefacing your template names with a short signifier, so ABC_ or Comp_, this is so the client can later develop other websites and easily distinguish between the templates meant for one over the other.All content under the home item should represent a page and have valid presentation. All other content should be stored within the global folder which is a sibling item to the root home node.
Is this good practice that we should use on all projects? 90% of the best practices we typically use can be applied as-is without modification. I would prefer to see at least some attempt made to consistency.
Are there disadvantages to this scheme? None, you should only be doing it if it makes sense, if it doesn’t then you’re not doing anyone any favours.
Are there better ways? Indubitably, I hope to find them out ;)
How should you decide when to store items in a global folder rather than under the home node? Only content that “belongs” to the item should be present. The approach to organising sitecore content should be functionally similar to database normalization. It should be in global folders if the content in question isn’t “owned” by the context item, this covers both things like sidemenu RTE blocks, control labels or if there is a many-to-one relationship of some sort.
Text that goes with a control or sublayout We did try name/value pairs for a while but frankly these suck. I’ve now switched to a set of custom configuration templates, one per rendering or sublayout. They have 2 sections, one for labels and one for configuration. The configuration node is set at the top of the renderings as a variable and as a private property on the sublayouts. I’ve been planning on automating this at some point however.Something which I don’t do but it worth considering is using the parameters templates which were introduced in 6.1. I’m not sure how usable this is for the content editors however, letting them go into the presentation interface is dangerous at the best of times.

Naming
Naming fields and field sections Field names should be programmatically sound with friendly names added later.
Naming templates, layouts, renderings etc. ProjectAcronym_TemplateName typically. Folders used as much as possible (note, not supported in workflows).
Name prefixes See above.
What other advice would you give on naming items? Clear, concise and SEO friendly. In the case of sublayouts and renderings make sure the item name matches the file name.

Project structure
What is the ideal structure for a Sitecore project? Start with the standard 4, Website, Business, Data and Tests. You’ll almost always end up creating them so why not do it from the start. Otherwise you tend to bloat up the website project with helper classes only to have to refactor later.
What are the worst mistakes that should be avoided? Omnidirectional project references, untilize dependency injection where possible.

Sitecore ORMs
What do you think about Sitecore ORMs? Tears, wailing, gnashing of teeth. Contentious issue but personally I think the issues it’s trying to solve are not as big as the problems it causes.
What problems does it solve? Very very good question. It’s can be cool that’s for sure. Templates as object, intelisense on your fields, that’s lovely. Then you run into the hell of lazy loading, caching and often a gradual and inexplicable delta between the database and the in memory objects.
Does it cause any problems of its own? See above.
Would you use shared source Domain Objects instead? Why? Never tried it to be honest.

Sublayouts and renderings
How do you decide whether to use one over the other? It’s not very scientific but I use the rule of thumb that if it’s not easy it’s time to switch to a sublayout. XSLT should make your life easier, not harder.
Are there dangers of too much reliance on XSLT? There can be issues with refactoring, due to its reliance on referencing items by paths and fields by names. I’ve got some grand ideas to help resolve that however via xslt helpers.
Are there dangers of too much reliance on sublayouts? Sitecore is designed with xslt in mind, if you use sublayouts where a simple xslt rendering could have done you’ve missed a trick.
Is one easier to maintain that the other? Loaded question. Ask someone who needs to rename every reference to an item by path and you’ll get one answer. Ask somone who needs to pull out a faulty ORM and you’ll get another. I think like most things you need a healthy balance really.

Testing
Can Sitecore projects benefit from unit testing? Strictly speaking no, Sitecore itself is impossible to properly unit test. Integration and stress testing however is vital.
WatiN? A recursive Watin test for the whole site to check for standard errors (missing presentation, failed xslt etc) should be standard on all sitecore sites.
What holds us back from doing more testing? Time, and occasional false perception of there not been enough time.

What else?
What factors cause sitecore projects to go well? When the site is been developed as a sitecore site, see next question for more.
What factors cause sitecore projects to go badly? When a site is been developed as something else. Sitecore projects typically fail when someone is trying to code something else into the system. Sitecore can be an application framework, but you’d be better off with MVC. Sitecore can be made to act like any other CMS or legacy system, but you’d be better off not doing it that way. Sitecore always *CAN*, but you probably shouldn’t.
What other questions should this survey have asked? I’m sure we can think up enough for a sequal at some point. This survey though was exhaustive and excellent, cheers ;)

 

 

Love to see what other peoples answers would be, if you do end up posting your answers online make sure you post a link to in the comments :)