Thank you for getting back to me so quickly. I will try and answer each of your questions below:
Q1. Please clarify: are you doing this from the Naked Objects UI or not? If
not please remnind us of that each time you raise a query - because otherwise we spend a lot of time chasing down the wrong avenue - and it might mislead other people also.
A1. My statement that "I am try to create and persist an instance of each of these types programmatically within an ObjectPersistor transaction. I.e. NakedObjectsContext.ObjectPersistor.StartTransaction/EndTransaction."
is probably ambiguous, so I will clarify;
I am not doing this from the NakedObjects UI. Note: I will try and always add this statement in future. Sorry for any time you have wasted.
Q2. If all you want to do is have a many-to-many relationship between an Application and a Role - can you not just delegate this to Entity Framework. If you specify a many-to-many relationship in the entity model then
EF will create an association table (that corresponds to your ApplicationRole object) but is never surfaced as an entity or an object. That's not to say there's never a reason to do it the way that you have (e.g. if the mapping itself needs to have additional
data associated with it such as start & end dates, or if the numbers involved are too large to represent as direct collections in the UI) - but I'd like to know if you did have a good reason for representing ApplicationRole as an explicit object.
A2. Our ApplicationRole type needs to have additional data associated with it, so I do have a good reason for representing the many to many relationship as an explicit object.
Q3. In your transaction that creates the ApplicationRole, how are you getting hold of the Application and the Role? Are you retrieving them afresh from the container, or have you held on to references to them from within the transactions
you created them in. If the latter, is it possible that you are holding onto the pre-persisted version of the object. N.B. the reason why the Persist method syntax is Perist(ref obj) is that the object itself is swapped when you persist it.
One way to test this is to assert, just before adding them in to the ApplicationRole object that the Application and the Role objects are in fact persisted at that point (by calling Container.IsPersistent(...) ).
A3. I retrieve both the Application and the Role references by using a LINQ query that selects them afresh from Container.Instances<T>(). I have also checked that the Application and Role objects are correctly persisted.