Core Data: Design questions. Object wrappers or not?

Question

I'm designing my first project using Core Data (for iPhone) and Im having some issues that might be related with my design approach.

I'm doing an application that allows the user to create an Order (let's say for a restaurant). I'm using the graphic designer to model my persistence object (i.e. OrdeMO). I add MO to the ead of each name to indicate its a Managed Object. I use XCode to create the Managed Object Class automatically.

I have created some "DAO" classes that allows you to search or create a new object in the Managed Context.

Now to my problem.

I want to create an OrderMO object to store the order the user is creating, BUT I don't want it to be part of the context until the user actually places it. I tried creating the object with [OrderMO alloc] but the object I get is "incomplete" and when I try to set any of its attribute I get an error.

I'm assuming the problem is that I need to create the order IN the context in order to use it. Is that so?

I have considered various options:

1. Create the object in the context and the user rollback if the user discards the order. The problem is that the user might save other context object during the process (like his prefs) so this doesn't work. Is there a way to create the object "inside a separate transaction" of sorts?

2. Create a wrapper object that will hold the same data as the MO, and then only create the MO when the user place the order. The downside of this is that I have to maintain a new class.

3. Create an attribute in the MO, such as "placed", and use to filter my searches in the context. The problem with this one is that I will end up with "trash" objects in the domain (i.e. unplaced orders) and I will have to do some cleanup from time to time...

Do I have any other choice?

Any suggestion is appreciated.

Thanks (for reading this long post!) Gonso

Answer 1

You should create the OrderMO object in the managed object context and then delete it if the user decides not to place the order.
If the context is saved before the object is deleted, the "trash" object will be deleted from the persistent store on the next save (if the context wasn't saved, the "trash" object will never be saved to the persistent store).
The flag to determine if the order was placed or not does not have to live in the OrderMO object as you suggest in option 3. It could be in the view controller that is tracking the order(s) that are being edited. And, again, you won't have "trash" objects because they will have been deleted.