Guidance on Handling Long Onboarding Processes and Large Objects with CSLA.NET

[theafricaninternetgroup]

I am developing a payroll application using CSLA.NET and have a couple of challenges related to the customer onboarding process and object design

1.Tracking User Progress in a Long Onboarding Process
The onboarding process involves multiple steps, and I would like to track the user's progress. When a user resumes the process after a break, they should be taken back to the last step they completed. Is there a recommended way to implement stateful workflows or track progress in CSLA.NET?

2.Segmented Input for Large Objects
One of the onboarding steps involves adding employees

My Employee object has 40-50 properties, and to save it, the object needs to be valid and dirty. However, the input process for employee data is segmented into smaller steps (e.g., entering personal details first, then contact information, etc.).

How can I manage the validity and dirtiness of the object across these segmented steps?
Is there a recommended approach for saving partial data or ensuring that rules are applied correctly during this segmented input process?

I would appreciate any best practices or examples on handling these scenarios.

Thank you in advance

[rockfordlhotka]

1.Tracking User Progress in a Long Onboarding Process The onboarding process involves multiple steps, and I would like to track the user's progress. When a user resumes the process after a break, they should be taken back to the last step they completed. Is there a recommended way to implement stateful workflows or track progress in CSLA.NET?

One approach is to create an object graph for each step in the process. One root per step, so that step can be saved independently.

When the user moves to the next step, the object graph for that step is created (loaded with data), and ultimately saved.

Remember that a create and a fetch operation are both able to interact with the database. This type of scenario is the reason that create is able to interact with the database: to load default or initial values into the object graph as necessary.

2.Segmented Input for Large Objects One of the onboarding steps involves adding employees

My Employee object has 40-50 properties, and to save it, the object needs to be valid and dirty. However, the input process for employee data is segmented into smaller steps (e.g., entering personal details first, then contact information, etc.).

How can I manage the validity and dirtiness of the object across these segmented steps? Is there a recommended approach for saving partial data or ensuring that rules are applied correctly during this segmented input process?

This can be tricky.

If each step in the process has rules that are independent of the other steps, then what I suggested earlier works well, because each step has its own types and that step's object graph can validate itself.

On the other hand, if a step can invalidate values from a previous step, then you need to load those values in both steps because those values are part of the validation rules for both object graphs.

This doesn't mean you need to bind or show all the values to the user, but you do need to have them available in memory for use by the rules engine.

[theafricaninternetgroup]

Thanks very much.