Consigli su LINQ to SQL oggetto di design mappatura

Question

Spero che il titolo e il testo che segue sono chiari, io non sono molto familiare con i termini corretti quindi per favore mi corregga se ho qualcosa di sbagliato. Sto usando LINQ ORM per la prima volta e sto pensando a come affrontare i seguenti.

Dire che ho due tabelle DB:

User
----
Id
Name


Phone
-----
Id
UserId
Model

Il generatore di codice Linq produce una serie di classi entità.

Ho poi scrivere il mio classi e interfacce che avvolgono queste classi Linq:

class DatabaseUser : IUser
{
    public DatabaseUser(User user)
    {
        _user = user;
    }

    public Guid Id 
    {
        get { return _user.Id; } 
    }

    ... etc
}

finora tutto bene.

Ora è abbastanza facile da trovare a utenti cellulari da Phones.Where(p => p.User = user) ma sicuramente comsumers della API non dovrebbe aver bisogno di scrivere le proprie query LINQ per arrivare a dei dati, in modo da dovrebbe avvolgere questa query in una funzione o una proprietà da qualche parte.

Quindi la domanda è, in questo esempio, sarebbe si aggiunge una proprietà Phones per IUSER o no?

In altre parole, dovrebbe essere la mia interfaccia specificamente modellare i miei oggetti di database (nel qual caso i telefoni non appartiene a IUSER), o sono in realtà semplicemente fornendo un insieme di funzioni e proprietà, che sono concettualmente associati a un utente (in qual caso lo fa)?

Ci sembra svantaggi di entrambi i punti di vista, ma mi chiedo se non v'è un approccio standard al problema. O semplicemente tutte le parole generali di saggezza che potrebbero condividere.

Il mio primo pensiero è stato quello di utilizzare metodi di estensione, ma in realtà che non funziona in questo caso.

Answer 1

Ho avuto alcune esperienze terribili che cercano di entità astratta dietro LinqToSql interfacce. Era qualche tempo fa, ma dalla memoria il problema principale era che si rompe totalmente associazioni. Ad esempio, se si dispone di un Customer -> rapporto Order, si finisce per essere esposti come un ICustomer, con una collezione di IOrders, il che significa che Customer ha a che fare un po 'di mappatura imbarazzante per lanciare la sua collezione interna di oggetti Order come IOrders <. / p>

Poi si deve supporre che quando un IOrder viene passato di nuovo in, che siamo in grado di lanciare a un Order. In caso contrario, LinqToSql non può trattare il caso, ma poi che sconfigge il punto di avere l'interfaccia lì in primo luogo.

vi consiglio vivamente di non cercare di astrarre le classi di entità troppo, LinqToSql non effettivamente messo alcuna vera magia in loro, il DataContext gestisce il ciclo di vita di persistenza, così rimangono verificabile.

Gli aspetti che mi sarebbe in cerca di nascondersi dietro un'interfaccia sarebbe interazioni con DataContext, ad esempio utilizzando le classi Repository stile:

public interface IPhoneRepository 
{
    IEnumerable<Phone> GetPhonesForUser(User user);
}

public class L2SPhoneRepository : IPhoneRepository
{
    private readonly MyDataContext context;

    public L2SPhoneRepository(MyDataContext context)
    {
        this.context = context;
    }

    public IEnumerable<Phone> GetPhonesForUser(User user)
    {
        return context.Phones.Where(p => p.User == user);
    }
}

Answer 2

L'interfaccia dovrebbe modellare come si vorrebbe per gli oggetti da utilizzare. Dal momento che si sta cercando di astrarre, quindi il consumatore non dovrebbe avere per interrogare il DB. Sia che si rendono una proprietà, o di una chiamata di funzione separato (cioè, GetPhones ()), è interamente a voi. Dal momento che si sta avvolgendo completamente le cose, si dovrà fare delle scelte su come profondo / pigramente si desidera caricare gli oggetti.

Answer 3

Si dovrebbe aggiungere proprietà cellulari per IUSER e renderlo annullabile, quindi per un utente che non hanno il telefono, sarà nullo.

Dal momento che non si desidera che i consumatori della API per scrivere query, quanto deve implementare funzioni come GetUser () .. etc.

Ecco una bella lista di applicazione dell'articolo circa n-tier in Asp.net

http://imar.spaanjaars.com/QuickDocId.aspx?quickdoc=416

Answer 4

tendo a considerare il Linq2Sql cose relative ad essere un dettaglio di implementazione del codice di accesso ai dati e, come la struttura reale del database, non deve necessariamente essere esposti ad altre parti del sistema.

Se l'API sta per essere consumato da altre persone dovrebbe essere coesa e facile da usare e non ingombra da cose il consumatore non ha bisogno di conoscere. Se ho a che fare con gli utenti ed i loro telefoni non voglio davvero sapere su DataContexts o (ugh) DataSet.

Inoltre, mantenendo la maggior parte del vostro codice ignorante delle L2S e del database si avrà un test di tempo più facile, rendendo modifiche dello schema (oh, così ora la tabella utente ha bisogno di mantenere una cronologia di tutte le modifiche apportate) o anche cambiando l'ORM completamente.