Object Graph / Persistence Question_问答_开发者

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 conce开发者_如何学运维rned 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.

I think it's perfectly valid to just build up your session state in the HTTPSession and commit at the end. If you need failover in this scenario, you can always use Terracotta clustered sessions, which will store your HTTPSession state in the Terracotta server (with varying levels of persistence). The server with the session could then die and Terracotta could resurrect it on another node.

You might check out Spring Webflow too - it deals with this sort of scenario in flow state (which is stored in the session too).

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.

I would personally go with the option to

populating/serializing/deserializing individual objects through the screens and then building the final object graph just before persisting to the database

for 2 reasons. Firstly if you build your application using smaller modules and piece the object graph together at the end it should make it easier to unit test and allow for parts/screen flows to be reused.

Secondly as requirements change over time there is a good chance that you will need alternate screen flows which will mean that you can't build your object graph up front and need to build your object as you go.

In posting my answer I've assumed that you have chosen the right technology model to fit the business requirements (see @Stephen C's comments).

I would say that one possible (high level) problem with your current approach is that your users' work is not saved until right at the end. This is not good if the screens take a long time to complete.

What would building beforehand be good for? If you are not concerned with Unit of Work and long business transaction issues, then your strategy is the best for your situation...