Il primo test che ho effettuato è già concluso miseramente.
Il modello di prova ha una serie di entities e ciascuna di queste ha i corrispettivi 'details' (Contact => ContactDetails, Document => DocumentDetails, etc.).
Ho scelto di avere una sola tabella Details per cui non posso avere la FK in Details che punta alla Contact e alla Document.
Creo quindi il DomainService in un progetto RIA, dopo aver cancellato il progetto Silverlight che è inutile per questo esempio:
[EnableClientAccess]
public class TestService : DbDomainService<BizContext>
{
[System.ServiceModel.DomainServices.Server.Query(IsDefault = true)]
public IQueryable<Contact> GetProducts()
{
return this.DbContext.Contacts;
}
...
Configuro l'endpoint (nel mio caso oData ma potrebbe essere anche SOAP o Json):
<system.serviceModel>
<domainServices>
<endpoints>
<add name="OData" type="System.ServiceModel.DomainServices.Hosting.ODataEndpointFactory, System.ServiceModel.DomainServices.Hosting.OData, Version=4.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" />
</endpoints>
</domainServices>
E purtroppo ottengo una YSOD con questo errore:
Unable to retrieve association information for association '….DataLayer.Contact_Details'. Only models that include foreign key information are supported
Un vecchio post conferma i sospetti, la FK è indispensabile.
A questo va aggiunto il noto problema delle relazioni molti a molti (http://forums.silverlight.net/p/90385/346173.aspx) (http://social.msdn.microsoft.com/Forums/is/adodotnetentityframework/thread/cc48da63-502d-4429-b90a-0c558b1b9c94) che addirittura è sfociato in un progetto di workaround su codeplex (http://m2m4ria.codeplex.com/).
I RIA services sono indubbiamente una manna per chi fa RAD e le più recenti aggiunte dell'endpoint JSon per supportare i client jQuery sono vere killer features.
Ma qui stiamo partendo dal presupposto che il Modello venga prima di tutto. Quindi:
- per i più svariati motivi viene prima fatto il design delle entity
- poi mappo le entity al database con la fluent-API della Code-first, e genero il DB di conseguenza
- quindi voglio 'nascondere' tutto dietro un servizio in modo da poter presentare i dati con la fondamentale IQueryable e per client di tipo differente:
- Silverlight via soap
- jQuery via json
- altri client via oData
In quest'ottica non posso stravolgere il modello solo perché RIA non capisce bene il mapping di EF 4.1 e quindi per certi scopi non sono la soluzione. Un vero peccato perché si perdono un certo numero di facilities che sarebbero realmente molto comode.
Altri esperimenti in vista …