5

In my solution, I have some Computed Index Fields that I need to add that combine the values of fields from templates that belong to multiple Project-layer modules. I am using DI for initializing my Computed Index Fields, all of which inherit an IComputedIndexField interface. The problem is that I'm not sure where I should put the derived index field types, or how I should properly reference template types that live in multiple Project-layer modules.

What would be the best way to do this? Am I totally off base?

  • 1
    I would question the layers if you have fields in multiple project layers that need to be in the same computed field. Sounds like the fields are defined at the wrong layer – Richard Seal Oct 25 '16 at 15:37
  • 1
    That may be. The site that I'm working on has a News section, and a People section. Initially, the items representing a "Person" had nothing to do with the authors of the "News Articles" and I was sure to confirm with the client that this would remain the case. Of course, a CR was made and now a Person can be an author of an article. The client wants to be able to search in the Sitecore UI for for a Person (first name, last name, or department) and see all of the news articles belonging to returned Persons at the end of the results. – Zachary Kniebel Oct 25 '16 at 15:47
  • 1
    News and People sound more like "Feature" layer than "Project" layer. If they are feature layer, then you could simply add the computed field in the project layer and reference both features. In fact Person could even be foundation and feature if it needs to be referenced by the News feature – Richard Seal Oct 25 '16 at 15:50
  • 1
    @RichardSeal I agree with this. – Søren Engel Oct 25 '16 at 16:09
  • 1
    I have upvoted everything on this page including comments.. Mainly because this entire conversation, including comments has been highly insightful to me. 5 stars, +1, would recommend. Wow. – Pete Navarra Oct 25 '16 at 17:24
4

Based on your comment above. You should move the definitions of those fields from the individual projects into a "Common" project in the Project Layer - you can then reference that in your individual Project Layer projects to keep the code as is.

Then you can put your computed field into the "Common" project.

It would only require a small refactor to do this, especially if you already have a Common project as the Habitat solution does.

  • 3
    Actually, depending on how the solution looks like, I would rather move the temples down to a lower level layer, and then reference them from a higher layer, like a feature module that contains the common search logic. By putting them into a common project layer module, you somewhat make your other project modules depend on an equally less stable dependency, which I would avoid. However, it all depends on your structure, so I'm answering from what is written so far. – Søren Engel Oct 25 '16 at 15:48
  • 3
    I agree completely. I was looking for a minimal refactoring solution based of @ZacharyKniebel's comments to your answer. – Richard Seal Oct 25 '16 at 15:50
  • 3
    @RichardSeal good catch - slip of the tongue. I updated my comment :) It was still my understanding that it would go against helix to add additional layers above the Project layer. Is this not the case? – Zachary Kniebel Oct 25 '16 at 15:56
  • 3
    @ZacharyKniebel I know the feeling, and it can be hard to refactor this late into the process. Problem is, if you take the easy route then you bring in technical debt, and might cause other devs to follow the same path, meaning that your architecture will start to decay at some point. Surely you can diverge from the principle in Helix, it's a guideline, but if you do it can have huge impact later on, so you should do so with caution. – Søren Engel Oct 25 '16 at 16:06
  • 3
    Still feel's like People and News should have been features not projects: helix.sitecore.net/principles/architecture-principles/… > The Feature layer contains concrete features of the solution as understood by the business owners and editors of the solution, for example news, articles, promotions, website search etc. – Richard Seal Oct 25 '16 at 16:09
4

Following the principles found in Helix, you should adhere to the Common Closure Principle:

Classes that change together are packaged together.

This means that you should define the computed index fields in the same place, as to where you define the fields on the Sitecore data templates - such that if the fields changes, your computed index should change together with it.

If you have multiple fields defined in your project layers, and you need to use these from multiple places, then you should consider moving these down into lower layers of your architecture, where you can reference them from your upper layers - without violating the Stable Dependency Principle.

  • 2
    I am totally aligned with the Common Closure Principle, but I have two templates that are used for two totally different things (and thus they were put in two totally different modules) but the client has requested that they be able to search for a combination of the value of a field on one of the templates and two fields on the other template. We are half-way through UAT and it's a little late to make a change of that magnitude. Moreover, I really don't feel that these two modules belong together. Do you have a work-around? – Zachary Kniebel Oct 25 '16 at 15:37
  • 1
    @ZacharyKniebel See my comments to Richard's answer down below. – Søren Engel Oct 25 '16 at 15:50
  • 1
    I agree with your comments on Richard's answer, including the one about the technical debt that I would incur if I go the easy route. I am going to add the additional Subproject layer, and will apply the fix from there. I will make sure I do a solid post-mortem on this to make sure I don't put myself in this situation again. – Zachary Kniebel Oct 25 '16 at 17:45

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.