I read this excellent tutorial (http://blogs.planbsoftware.co.nz/?p=247) about NserviceBus Sagas, but still I don't understand what is the advantage of this model (sagas), over using database or business layer transactions?
2 Answers
The main benefit of the saga model is that it allows you to take logic and data that would otherwise be spread out across a system (and various batch jobs), and pull that all into a single class, better following the single responsibility principle. Once you have that, you get all the other benefits that come from good software practices - better testability, maintainability, etc.

- 11,932
- 1
- 27
- 35
-
Many Thanks Udi. Can you point me a simple dummy example that implements something both ways, so I can really understand the difference? I agree that the state data would be spread across the system, but maybe my existential question is: If that data makes part of the business process (and we might need to query that state data for reports, to let the client know the current status, etc) doesn't make sense to store the State data together with the business data? Thanks again. – Miguel Jun 03 '16 at 12:41
-
I'll put that next on the list of things to do :) But seriously, you can totally query the saga data directly - it is persisted to a regular DB. – Udi Dahan Jun 04 '16 at 06:51
-
I think I see...So the process using SagaData acts as a distributed transaction coordinator with access to the state in the several systems involved in the transaction, right? – Miguel Domingos Jun 04 '16 at 19:02
-
I wouldn't describe it that way at all. The saga class is the only class that operates on the SagaData. When using a saga, any coordination across various systems would be done in a non-transactional message-driven manner. – Udi Dahan Jun 05 '16 at 13:09
To show you real benefit of Saga model I'l show you two examples.
Imagine you have Services Oriented Architecture with hundreds of distributed hosts. Customer makes an Order that starts one or more sagas. Each saga have some related business logic. Handler for each given saga can be shared between different hosts and you don't need to check order state handling each message, NServiceBus implicitly checks saga state matching it by order id or other attributes and if it is still opened you'll get it in your data context.
You can also use this model as pattern without NServiceBus usage. Imagine you develop a video game and want to track some user combos. Each time player hits jump you open saga and add bonus points handling other rapid input. Once player delays for some time between inputs and saga closes itself saving total score for combo.
What are the benefits of Saga?
1) Your business logic is encapsulated in one place - saga.
2) You can extend it easily adding additional saga or removing them. You can also move them to other handlers or hosts.
3) You don't need to know what data in database are required in case of migration, you just need to migrate sagas which contain all necessary info

- 2,034
- 1
- 27
- 38