views:

274

answers:

3

Hi,

What is the best practice with regard to the Entity Framework and validating new objects prior to persisting them (or in other words calling .SaveChanges()) when the new object may rely on either persisted objects or other new objects?

For example, consider the following:

Entity1 MyEntity1 = new Entity1();
MyEntity1.Name = "Hornblower";
DataContext.Entity1s.Add(MyEntity1);

.... Other code ....

Entity2 MyEntity2 = new Entity2();
MyEntity2.Entity1s.Add(MyEntity1);

.... Other code ....

// Validate that MyEntity2 has at least 1 Entity1 relationship
if (MyEntity2.Entity1s.Count() > 0 )
{
    // Valid - save it
    DataContext.SaveChanges();
} else {
    // Invalid - handle it
}

In the above pseudo code, would this be a valid and correct method of validating the required conditions - can the .Count() be relied upon to return both persisted MyEntity1s and non-persisted MyEntity1s, and thus in the above case cause the validation to succeed?

Or should I be persisting MyEntity1 prior to attaching it to MyEntity2?

Regards

Moo

A: 

Cardinality of your relationships is part of your model and does not require separate validation. If you require 1..* instead of 0..*, then define the model that way and the EF will validate it for you.

Craig Stuntz
Hmm, I guess I was asking for that - I never really even thought of that, and yes it means my design is wrong. Thanks!
Moo
Ahh, having looked, this is why I haven't implemented it in the model - the EF doesn't look to have a way for me to specify that the Entity1-Entity2 relationship should consist of '1 or more' on the Entity2 side, just '0 or 1' or '1'. So its back to the validation to do it.
Moo
You can do it from the other side, but it isn't clear from your question whether that's applicable here. Depends on how you use that side.
Craig Stuntz
In this case, consider Entity2 to be a 'Business', and 'Entity1' to be 'Relationship' (relationship between 'you' and 'Business X', not a database relationship.For example, you may have a 'Supplier' relationship with a business, and also a 'Client' relationship with the same business, or they may simply be a 'Lead' but you do have at least one relationship with that business, potentially more.
Moo
A: 

I'd consider first using a simplified saving that would only save your current (game?) state and not all your Entity System objects. Like: "player is at level @123,456 items Foo, Bar".

The other way could be to serialize and then deserialized your objects. Start with a root object, and during the serialization, also serialize all dependencies. This option can be very complex, especially with opened files, conenxions, and other elements that are not serializable.

Wernight
A: 

Hello,

Your code is a bit dis-jointed.

You have attached MyEntity1 to the ObjectContext by calling

DataContext.Entity1s.Add(MyEntity1);

but have not attached (or have not shown in the example) MyEntity2 to the Context.

That being besides the point, the short answer is Yes. Your validation will hold true and will pass as being valid.

Reasoning:

Entity manipulation is independent of Object Context. When adding or removing associations from entities, changes are reflected on the entities regardless of its state in relation to the Object Context that manages it.

Pitfall

Your real problem will be when calling SavingChanges() to the Context. When trying to persist entities (namely entity graphs), you must be aware that the context is very sensitive to Object States. This means you cannot persist an entity graph of mixed attached and detached entities.

Tri Q