Domyślnie kolekcje i referencje do innych encji używają opóźnionego ładowania (lazy loading). Wszystkie encje podlegające temu mechanizmowi są ładowane w tle(w sposób niewidoczny dla programisty) w momencie kiedy wymagany jest do nich dostęp. Załóżmy, że mamy encję Invoice, która zawiera kolekcję produktów:

class Invoice
{
    EntityCollection<Product> Products{get;set;}
    public string ReceiverName{get;set;}
    public string IssuerName{get;set;}
}

Gdy użyjemy zapytania odczytującego fakturę, zostaną zwrócone wyłącznie właściwości ReceiverName oraz IssuerName – bez kolekcji Products.

W większości przypadków mechanizm opóźnionego ładowania sprawdza się, jednak czasami chcemy mieć od razu zarówno wszystkie właściwości jak i kolekcje danych – bez potrzeby wysyłania dodatkowego zapytania o kolekcje w drugim zapytaniu. W takim przypadku musimy skorzystać z eager loading(ładowanie zachłanne).

Użycie eager loading w RIA Services składa się z dwóch etapów: skonfigurowania metadanych oraz wywołania metody include przy odczytywaniu danych.

Metadane konfigurujemy za pomocą klas częściowych w bibliotece w której posiadamy model encji(ADO .NET Entity Data Model):

[MetadataType(typeof(Invoice.InvoiceMetadata))]
public partial class Invoice
{
   internal sealed class InvoiceMetadata
   {
       [Include]
       public EntityCollection<Product> Products;
   }

}

Następnie dopisujemy metodę w DomainService:

public IQueryable<Invoice> GetInvoiceWithProducts()
{
  return this.ObjectContext.InvoiceSet.Include("Products");
}

Zwróćcie uwagę na metodę Include – to ona jest odpowiedzialna za eager loading. Teraz po stronie klienta możemy załadować wszystkie faktury wraz z produktami za pomocą poniższego kodu:

m_DataContext.Load<Entities.Invoice>(m_DataContext.GetInvoiceWithProducts());

Dziś postanowiłem wyjaśnić problem, który zauważyłem jest często poruszany na forach. Załóżmy, że wywołujemy metodę SubmitChanges aby zatwierdzić wprowadzone modyfikacje. Wykonanie metody jednak nie powodzi się i wyrzucany jest wyjątek. Scenariusz wygląda typowo jednak często otrzymujemy mało mówiący komunikat typu:

Submit operation failed. Exception has been thrown by the target of an invocation.

lub

Submit operation failed. An error occurred while updating the entries. See the InnerException for details.

Co gorsza, jeśli zajrzymy do InnerException zobaczymy wartość NULL. Oczywiście mówimy ciągle o stronie klienta. Pytanie brzmi więc: W jaki sposób możemy podejrzeć co tak naprawdę stało się?

Rozwiązaniem jest przeładowanie metody Submit(DomainService) lub OnError(DomainService) oraz obsłużenie tam ewentualnych wyjątków:

public override bool Submit(ChangeSet changeSet)
{
  try
  {
      return base.Submit(changeSet);
  }
  catch (Exception e)
  {
      throw;
  }
}

Jeśli zajrzymy do InnerException zobaczymy, że wyjątek jest tam zapisany i możemy przeczytać dokładniejszą informację np.

Violation of PRIMARY KEY constraint 'PK_Table.Tests'. Cannot insert duplicate key in object 'TestModule.Tests'.
The statement has been terminated.

Rozwiązanie jest być może niezbyt eleganckie ale działa bez zarzutu.