EF 5 DbContext: Delete the undeletable - entity-framework

Question

I'm using EF5 with DbContext and Database-First approach in a WPF application and ran into some logical problems during the deletion of entities and the usage of the required data annotation attribute in the following scenario:
The are two tables referencing each other with foreign keys without cascading delete:
|----A----| |----B----|
|ID int |<-| |ID int |
|---------| |-|A_ID int |
Thus, "A" can't be deleted if some "B" references "A".
The EF 5 model includes the associations and - as no cascading is set - OnDelete is set to "None" to both Ends of the associations. I've decorated both the "A_ID" field and the Navigation property "B.A" with a [Required] attribute - and here my trouble starts when I delete an "A" entity with "B" entities refrenencing this "A" entity:
MyContext.Set<A>().Remove(MyA);
MyContext.SaveChanges();
SaveChanges sets all navigation propoerties of "B" to the removed "A" entity to null. This invalidates "B" as the navigation propoerties have the Required-Attribute throwing an exception that "A" can not be deleted because "B" is invalid - which is somehow a strange reason.
However, after removing the Required-Attribute on the Navigation properties and leaving the Required-Attribute on the B.A_ID property the correct error is thrown.
Finally, after the database exception I end up with an object graph in which all naviagation properties of "A" are set to "null".
I think this is the intended behaviour of the EF but this leads to two problems:
Firstly, the delete Operation is not valid. I haven't found anything about a "Delete"-Validation. Data annotaions consider only property changes.
Secondly, how to recover removed entities after an exception as all navigation properties are set to "null". The EF 5 associations are not as precise as the SQL Server ones which allows "None", "Set to NULL" or "Cascade" on associations. In the case of "None" SQL Server throws an exceptions leaving all entities untouched.
If anybody ran into the same problems of a "CanDelete"-Validation and entity recovery after an database exception and has a solution or can point me to other related threads, please tell me.
Yours,
Marcus
Example Classes:
// Entity to delete
public partial class A {
public A() {
this.Bs = new HashSet<B>();
}
public int ID { get; set; }
public Nullable<int> C_ID { get; set; }
public string Name { get; set; }
public virtual C C { get; set; }
public virtual ICollection<B> Bs { get; set; }
}
// Child entities of A with foreign key constraint
public partial class B {
public int ID { get; set; }
public int A_ID { get; set; }
public string Name { get; set; }
public virtual A A { get; set; }
}
// Example class of an additional entity referencing A
public partial class C {
public C() {
this.As = new HashSet<A>();
}
public int ID { get; set; }
public string Name { get; set; }
public virtual ICollection<A> As { get; set; }
}
Database Schema:
CREATE DATABASE [EFABC]
GO
USE [EFABC]
GO
CREATE TABLE [dbo].[tA](
[ID] [int] IDENTITY(1,1) NOT NULL,
[C_ID] [int] NULL,
[Name] [nvarchar](50) NULL,
CONSTRAINT [PK_tA] PRIMARY KEY CLUSTERED
(
[ID] ASC
) ON [PRIMARY]
) ON [PRIMARY]
GO
CREATE TABLE [dbo].[tB](
[ID] [int] IDENTITY(1,1) NOT NULL,
[A_ID] [int] NOT NULL,
[Name] [nvarchar](50) NULL,
CONSTRAINT [PK_tB] PRIMARY KEY CLUSTERED
(
[ID] ASC
) ON [PRIMARY]
) ON [PRIMARY]
GO
CREATE TABLE [dbo].[tC](
[ID] [int] IDENTITY(1,1) NOT NULL,
[Name] [nvarchar](50) NULL,
CONSTRAINT [PK_tC] PRIMARY KEY CLUSTERED
(
[ID] ASC
) ON [PRIMARY]
) ON [PRIMARY]
GO
ALTER TABLE [dbo].[tA] WITH CHECK ADD CONSTRAINT [FK_tA_tC] FOREIGN KEY([C_ID])
REFERENCES [dbo].[tC] ([ID])
GO
ALTER TABLE [dbo].[tA] CHECK CONSTRAINT [FK_tA_tC]
GO
ALTER TABLE [dbo].[tB] WITH CHECK ADD CONSTRAINT [FK_tB_tA] FOREIGN KEY([A_ID])
REFERENCES [dbo].[tA] ([ID])
GO
ALTER TABLE [dbo].[tB] CHECK CONSTRAINT [FK_tB_tA]
GO

Answer 1

Simply delete all the B entities before you delete your A entity
[Update]
Since it is database first, the fact that your B Class contains
public int A_ID { get; set; }
makes me think that the relationship is not quite as you describe.
Try looking at in a database diagram.

Answer 2

As this behaviour is intended by the EF I used a workaround for WPF applications using DbContext. The problem occurs because I use a DbContext instance during the lifetime of a window. Thus, the object graph in the context has to be consistent until the window is closed. In the case of a failed delete operation whether because of foreign key constraints or because of a database connection failure the object graph is changed during the remove method.
As a workaround I have implemented the following methods:
Check foreign key constraints before the removal of entities.
As only the loaded object graph is affected only loaded entities have to be checked. This is not completely satisfying as the business logic has to implement this check independently from the EF which already knows all constraints.
Delete Entities in a separate DbContext
This way the original context isn’t changed if the deletion failed. This works fine for situations in which a window is equivalent to an deleted entity. In this case the window is closed if the delete operation succeded and held open with its original context if the delete operation fails. However, the situation in which the deletion of sub-entities fails isn’t covered with this method.
Finally, you could refresh the whole context after the failure of a delete operation but in this case you’re losing all changes in entities set before.