A new EM in the popup VM makes sense. But what about other scenarios? Many of us divide a complex screen into multiple views, each supported by its own VM. These VMs interoperate and it is convenient (not to mention performant) when these VMs share a common UoW.

Thanks for your feedback – and your opinions!

I lumped the ContactCompany into a ContactRepository in my mind – sorry for the confusion.

The use of a new EntityManager per ViewModel to encapsulate a UnitOfWork seems reasonable; particularly since CheckpointManager has been deprecated.  The goal is to isolate changes to data bound entities occurring in a popup dialog (for example) from the main entity cache until the user commits those changes (by selecting OK on the popup).  Of course this wouldn’t be necessary in a ViewModel that is presenting read-only data, but if it’s not a performance burden, I’d prefer to incorporate it into a view model base class.  Does that sound reasonable?

EndEditCore is indeed being called at save time (in my tests at least) without any previous call to BeginEdit, but if that isn’t guaranteed, I won’t rely on it.  I’m already iterating over the entities to be saved in an EntityManger.Saving event handler for other things, so adding a virtual PrepareSave method on my EntityBase class and calling it during save should get the job done.

Ahh – the connection between AcceptChanges and subsequent UPDATE versus INSERT actions is good to know.  My half-baked testing thus far was only focusing on various create scenarios.  And I didn’t realize that calling RejectChanges() on one entity affects other related entities (i.e. automatically clearing Contact.CompanyId when Company.EntityAspect.RejectChanges is called)  - that is much cleaner – thanks!

My focus on keeping the entity management code internal to the entities is driven partly by our development scenario.  A developer on the team could slap a list of Contacts into an editable grid and expose something like Company.Name to the user.  If I can make it behave as expected, allowing edits and throwing standard validation errors, it makes that developer’s life easier.  They’re not going to need to be concerned whether they can bind to Company or have to use ContactCompany instead, and they won’t see (or maintain) the gunk inside the entities that makes it work.  And, so far at least, I don’t see this sort of thing lead to any worse level of complexity in the entity classes than typical verification/validation.

Thanks again for your insights – much appreciated!

1. Add an internal "IsNewAndUnchanged" flag to the Company; it will be false by default. Do not make it public.
2. Set it "true" at the end of your Company.Create
3. Set it "false" if and when there is any subsequent change to this Company entity
4. In the EntityManager.Saving event handler, ask the Contact to prepare itself for save (e.g., validate itself)
5. Such preparation can test its Company's IsNewAndUnchanged flag; if that is true, you call contact.Company.EntityAspect.RejectChanges() and it will go away.
6. You should have a validation rule that prevents saving of a Company for which this flag is true without regard for whether it is the child of a Contact; chances are you don't want such a thing in your database.

Thanks for your thoughtful reply.

Basically what I am doing is setting a Company to “new” and “not dirty” when initially created, but then breaking the Contact/Company relationship at Contact save time if it is still new and unchanged.  I plan to deal with the scenario of clearing an existing Company name, etc. through validation rules.  This will employ significant logic involving other aspects of Contact/Company not discussed here.  And regardless of any wrapper layers, I believe that kind of validation checking belongs directly in the model objects, as the Validation subsystem seems to provide for.

Contact.cs

namespace DomainModel

{

    public partial class Contact : EntityBase

    {

        public static Contact Create(iCatalystEntityManager manager)

        {

            Contact contact = manager.CreateEntity<Contact>();

            contact.ContactId = Guid.NewGuid();

            contact.EntityAspect.AddToManager();

            contact.Company = Company.Create(manager);

            return contact;

        }

        /// <summary>

        /// Called upon SaveChanges regardless of whether BeginEdit was called previously or not.

        /// </summary>

        protected override void EndEditCore()

        {

            base.EndEditCore();

            if (!Company.EntityAspect.HasChanges() && Company.IsNew)

            {

        }

    }

}

Company.cs

namespace DomainModel

{

    public partial class Company : EntityBase

        public static Company Create(iCatalystEntityManager manager)

        {

            Company company = manager.CreateEntity<Company>();

            company.CompanyId = Guid.NewGuid();

            company.EntityAspect.AddToManager();

            company.EntityAspect.AcceptChanges();

            company.IsNew = true;

            return company;

        }

    }

}

Consider a typical WPF application where you display a screen with contact information.  On the screen are multiple textbox controls bound to, for example, Contact.FirstName, Contact.LastName and Contact.Company.Name.  The Name field on Company is required, but the Company property/FK relation is nullable.  The user supplies input to the LastName and FirstName fields, and leaves the Company.Name field empty, since this particular contact has no company affiliation.

How would you recommend handling this situation to allow Contact to save, while recognizing the Company should not be saved (in fact, cannot be saved since a value for Name has not been provided)?

I show my very standard Create methods for Contact and Company below.

 In the Contact class:

 public static Contact Create(IbEm.EntityManager manager)

        {

            Contact contact = manager.CreateEntity<Contact>();

            contact.ContactId = Guid.NewGuid();

            contact.EntityAspect.AddToManager();

            contact.Company = Company.Create(contact.EntityManager);

            return contact;

        }

In the Company class:

        public static Company Create(IbEm.EntityManager manager)

        {

            Company company = manager.CreateEntity<Company>();

            company.CompanyId = Guid.NewGuid();

            company.EntityAspect.AddToManager();

            return company;

        }

If we create a Company object as part of the Contact creation, how do we know not to save it when it has no Name value?  I have considered calling Company.EntityAspect. AcceptChanges() as part of my Contact Create method and implementing logic in a Saving event handler to call SetAdded as necessary, but that creates a problem since Contact.CompanyId now has a value with no corresponding Company record.

I would expect this type of situation to arise frequently when dealing with non-trivial binding scenarios, so I am looking for a broadly applicable technique.

Thanks for your help.