I prefer either of thefollowing:

• 1.     Two properties: onefor all and one for active books
• 2.     A property thatreturns only active books; a method (“GetAllBooks()”) that returns everything. 

#2 is cleanest but you can’tbind to a method … which is why I usually end up with #1.  

Think about what Author.Booksshould return in the usual case.  Should it (a) return all books or (b)return active books. 

DevForce by default generates a“Books” property for the (a) interpretation.  Most people want the “Books”property to behave like (b). Therefore, I would: 

1. ·       Rename (in the EDM)the “Books” navigation property to “AllBooks” (or some such convention)
2. ·       Add a custom “Books”property to the Author partial class that returns only active books. 

One possible implementation ofthat custom property is: 

 public partial class // extends the generated Author class
 {
     /// <summary>Gets the Author’s active Books (books thatare not deleted).</summary>
     [Bindable(false)]
     [Display(Name = "Books", AutoGenerateField = false)]
     public RelatedEntityList<Book> Books
     {
         get { return new RelatedEntityList<Book>(
                  this.Books.Where(b=>b.Active == true),
                  PropertyMetadata.Books.GetEntityReference(this)
                  ); }
     }
 }

It is no accident that thislooks very similar to the code that DevForce generated for Author.AllBooks. 

It is not the only possibleimplementation. RelatedEntityList<T> is a DevForce internal class … one that, in general, youshould not create yourself. The advantage is that this is a “live” list; if youtoggle a Book between active and deleted, this list updates automatically(adding or removing a Book automatically).