Few questions related to Helix

Question

• Code Generation, GlassMapper for each feature: We have following TDS implementation in our solution:

  One TDS project for each feature/foundation projects to pull corresponding items related to those projects

To accomplish this we have to refer Glassmapper assemblies and configs individually to all the feature or foundation projects. For e.g., Navigation Feature will have its own TDS project for item versioning as well as code generation and so on for all other projects. Another option we thought of was to move Glassmapper completely to foundation layer and use TDS generated classes from Foundation layer, but that would breach helix principles as feature templates will have to be pulled to foundation layer. Can you please let us know if there is another approach to restrict Glass mapper reference to minimal projects or if current approach is the best that can be achieved?

• Dependency Injection : We are starting off with a new Project and we are using Helix principles. We have implemented Dependency Injection using the Configurator Approach and referred to kamsar’s blog for the same http://kamsar.net/index.php/2016/08/Dependency-Injection-in-Sitecore-8-2/ Steps we followed are:

  Created a Dependency Injection project in Foundation. Added NuGet reference of Micrsoft.Extensions.DependencyInjection.Abstractions 1.0 Added the class ServiceCollectionExtensions given by Kamsar.

So, whenever we create a new Feature Project we must perform the following steps:

• Add reference to the Foundation project.
• Add NuGet Reference of Micrsoft.Extensions.DependencyInjection.Abstractions 1.0
• Create a class RegisterDependencies and add repository classes to Service collection.
• Add a config and add the RegisterDependencies class as a configurator in Sitecore services section in the config.

Two things:

• We wanted to check with you whether our current implementation is a correct approach or not. At the same time, if you know of a better approach then please let us know.
• Can you tell us if we can implement Dependency Injection using Sitecore’s best practices as well as helix principles and register dependencies at a single location – i.e. say at the Foundation Project.

Out structure

• Social media options for sites under same tenant: We have structure like this

• Tenant1
  -- SiteA
  -- SiteB

Now, if you look at Habitat example -- For Footer menu it has folder like this --
Now, what if SiteA and SiteB both has their own set of Footer options and they both have same footer rendering - We have few options to make this possible. But would like to know what's the best way to get this done.

Answer 1

DI Approach

We do exactly what you do. We have a dependency injection Foundation project that holds all the bits from Kamsar's post. Then I pull it all in with a config patch.

  <sitecore>
    <services>
      <configurator type="Sitecore.Foundation.DependencyInjection.ServicesConfigurator.DiConfigurator, Sitecore.Foundation.DependencyInjection" />
    </services>
  </sitecore>

Then in each feature get a configuration class that allows me to add interfaces as well as use Kamsar's bits to register controllers.

public class DiConfigurator : IServicesConfigurator
    {
        public void Configure(IServiceCollection serviceCollection)
        {
            // register each repository and service
            serviceCollection.AddScoped<INavigationRepository, NavigationRepository>();
            serviceCollection.AddScoped<INavigationService, NavigationService>();

            // add all controllers for this assembly
            serviceCollection.AddMvcControllersInCurrentAssembly();

            // see what is registered at /sitecore/admin/showservicesconfig.aspx
        }
    }

Then I pull that in with a config patch

<sitecore>
  <services>
    <configurator type="Sitecore.Feature.Navigation.ServicesConfigurator.DiConfigurator, Bonfire.Feature.Navigation" />
  </services>
</sitecore>

Footer

As far as the footer goes, if the two sites are sharing the same rendering, then the data is most likely the same. So you can allow them to have their different footers via Footer items in the site's settings. Same data structure, but different data that represents the footer.

If you are wanting to switch out the footer's dependency on the fly based on the site, I am not sure if that is such a good idea. If it got that complicated, I would just make a new footer for each "different" site at the project level.