1

Looking at the way the Habitat site logs users in has got me thinking.

It seems overly complex to me. I presume I'm missing some important concept, but what?

  1. The feature accounts controller calls login
  2. This logs the user in then calls the Foundation method RunLoggedIn which initiates the accounts.loggedIn pipeline
  3. This pipeline points back to a method in the Accounts Feature project which then tracks the user in xDb

Guess my question is .. why bother running a pipeline from Foundation? Shouldn't tracking etc. be done in the Feature (which it is technically, it's just via the Foundation layer). In which case login is simply .. auth.login(user) -> xdb.identify?

Or is it done this way so the pipeline can be extended to include other actions if needed too. If so, why isn't everything designed as a pipeline?

Seems a tad overcomplicated.

What is the benefit of a pipeline in this scenario?

  • You might need to zero in a bit, on what your question is exactly. If what you want is a discussion instead; Community is a better format. – Mark Cassidy Jul 18 '17 at 13:27
1

Before I answer, I should preface by saying that I think this is an opinion-based question that might generate better discussion on Sitecore Community Slack. Having said that, my opinion is below.

If you have a highly scaled solution (which habitat is meant to be an example of a scalable solution) then you might have more than one authentication feature with unique tracking logic or you may have project-specific tracking logic for specific sites or tenants. In these cases, the application still requires that when a user authenticates his contact is identified. We can say this because the feature calls an extensible (important for scalability) pipeline in the Foundation layer, which then calls a method implemented in the feature layer (so that it can have different logic for each implementing feature) that performs the contact identification.

The idea here is that not only does this make the solution more extensible and scalable, but if you were to start a new project you could take the foundation layer with you and likely some of the features and reuse it as a starting point. Of course, if you reuse it in a far simpler solution then, yes, you will likely have logic that is far more complicated than what you would have otherwise needed, but the trade-off is that you don't actually have to write any of it from scratch. All you would have to do is write the implementing logic that identifies the contact, which is required for the code to run so it's even self-documenting for developers of all skill-levels. In other words, while it may be more complicated than what you need it will work "every time" (grain of salt) and will require less coding and documentation (maybe even has reusable documentation), and thus will be cheaper than writing it from scratch.

Update: What is the benefit of a pipeline in this scenario?

Pipelines are great because they're extensible. You can add an implementing processor in any layer (of course, put it in the layer most appropriate for your use-case; usually in the foundation or feature layers), and can patch it in from that layer as well. This means that processors are one of those wonderful tools that have minimal risk of violating the directions of your dependencies, and if you ever need to change or extend the behavior later you can do so without actually removing or modifying the code that's already been deployed, but rather you can just add a new DLL to it. I could talk for ages about the benefits of a pipeline in most any scenario.

  • Cool. This kinda makes sense now. So, in essence, the feature could pass in which pipeline to run for authentication (habitat doesn't, but it could). So, one pipeline processor would do 'abc', another might do 'acd' - but both achieve the objective of authentication and "other stuff"? – stuartw87 Jul 18 '17 at 15:16
  • Exactly, and all could be extended or replaced without breaking the pattern. Future-proofing. – Zachary Kniebel Jul 18 '17 at 15:35

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.