I’m currently working with an online application that requires multiple screens/steps in order to complete. The application domain is modeled using an object graph. Persistence to and from a database is done using an ORM package.
As I progress through the screens I build up the object graph. Between screens I serialize/deserialize the object graph to the current session. By the time I reach the final screen, the object graph is complete and I store it in my database.
My question is the following. I’m not terribly concerned with patterns such as Unit of Work. I’m simply wondering if building the object graph beforehand, then populating as I progress through the screens and finally saving it is a viable strategy. Or perhaps populating/serializing/deserializing individual objects through the screens and then building the final object graph just before persisting to the database may make more sense. Or if there’s an altogether better approach.
I’ve chosen to temporarily persist to the session as I gather the pieces due to the fact that if the user abandons the process it’ll simply expire and I won’t have to search a database to purge abandoned applications.
I hope my question is stated clearly enough. This seems quite common.
EDIT:
My main concern with my object graph approach is although I’m working in my domain model, I feel like each time I need to update a portion of it I incur the cost of deserializing / serializing the entire graph. Maybe I should have an intermediate abstraction between my screens and the final domain model. I’m using ASP.NET / C# as my implementation platform.
The last time I wrote an application like this, I had a distinct model for each step – a one-one correlation between data entity and user interface (mostly). Keeping the objects small and workflow-bound made it much easier to make changes to a single step or reorder the workflow, without forcing huge rewrites of the application.