2

I've created my own helix based solution on the habitat project and I need to support multiple sites in this solution. But I don't know how to structure the Project folder here I need to create is the following basic structure the right approach or did I miss something?

  • Project
    • Common
    • DotComWeb
    • DotComCommon
    • ShopsWeb
    • ShopsCommon
  • I hope you aren't using the habitat solution to start building out a new solution for your company, since it's not a starter kit. If you are using it for learning purposes than this is fine and ignore me. – Dylan Young Sep 24 '18 at 22:10
  • @DylanYoung No I've created my own complete new solution, I am just using the Gulp Task and Serialization setup from Habitat and the overall Structure but no projects and so on. – squadwuschel Sep 25 '18 at 6:21
  • Maybe I'll get shamed, but we actually found Sitecore.Foundation.Assets, Sitecore.Foundation.Dictionary, Sitecore.Foundation.FieldEditor, Sitecore.Foundation.LocalDatasource, and Sitecore.Foundation.SitecoreExtensions to be rather helpful. TeamCity complains about C# coding standard issues which bumps up our issue counts, but otherwise these are pretty solid. – James Skemp Sep 25 '18 at 12:40
  • @JamesSkemp Yes I am also looking forward to this Modules to use them in the near future I hope this is ok :-) – squadwuschel Sep 25 '18 at 13:49
  • Copy Habitat modules at your own risk. They are not supported by Sitecore. Better to incorporate and customize to your requirements. – techphoria414 Oct 3 '18 at 15:02
7

When I was setting up our project layer based upon the Helix architecture principles for the project layer, this bit stood out to me:

Typically, in a single tenant solution there will only be a single module, namely the specific website or requirements that fits the needs of the tenant, and this will contain little or no pre-compiled code but instead consist of mark-up, styling, layout and templates of the item types in Sitecore which the editors can create (see Template types).

And for Habitat:

"The Common module paves the way for a multi-tenant implementation by defining some of the shared templates and settings between tenants."

So our current structure looks very similar:

  • Project
    • AbcWebsite
    • Common
    • QrsWebsite
    • XyzWebsite

What I'm not sure is what the use case would be for another Common project for each website, as you've done.

Unless you have multiple multi-tenant implementations with their own shared code, I wouldn't expect you'd need another common project for each website. And if you do have multi-tenant implementations like that (such as if each multi-tenant instance is a different client/customer), I wonder if that should instead be a different Visual Studio solution, one for each client/multi-tenant instance.

This also means that if you don't have a multi-tenant solution, a Common project layer module wouldn't be required.

  • 1
    my above code was just an example what I thought it would look like :-) – squadwuschel Sep 25 '18 at 6:23
  • :) Glad this helped! – James Skemp Sep 25 '18 at 12:38

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.