Tipps von Linq to SQL-Mapping Objektdesign

Question

ich hoffe, den Titel und folgender Text ist klar, ich bin nicht sehr vertraut mit den richtigen Begriffen so bitte korrigieren Sie mich, wenn ich etwas falsch. Ich verwende Linq ORM zum ersten Mal und ich frage mich, wie die folgende Adresse.

sagen, ich habe zwei DB-Tabellen:

User
----
Id
Name


Phone
-----
Id
UserId
Model

Der Linq-Code-Generator erzeugt eine Reihe von Entitätsklassen.

ich meine eigenen Klassen und Schnittstellen dann schreiben, die diese Linq Klassen wickeln:

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

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

    ... etc
}

so weit so gut.

Jetzt ist es einfach genug, um ein Benutzer-Handys von Phones.Where(p => p.User = user) zu finden, aber sicher comsumers der API nicht benötigen, sollte ihre eigenen Linq-Abfragen zu schreiben um Daten zu erhalten, so dass ich diese Abfrage in einer Funktion oder Eigenschaft irgendwo wickeln sollte.

Die Frage ist also, in diesem Beispiel würden Sie eine Telefon-Eigenschaft auf IUser hinzufügen oder nicht?

Mit anderen Worten, sollte meine Schnittstelle sein speziell meine Datenbankobjekte Modellierung (in diesem Fall Handys gehören nicht in IUser), oder sind sie tatsächlich einfach eine Reihe von Funktionen und Eigenschaften bereitstellt, die mit einem Benutzer konzeptionell verbunden sind (in wobei es der Fall ist)?

Es scheint Nachteile für beide Ansichten, aber ich frage mich, ob es einen Standardansatz für das Problem ist. Oder einfach nur irgendwelche allgemeinen Worte der Weisheit kann man teilen.

Mein erster Gedanke war, um den Einsatz Erweiterungsmethoden, aber in der Tat, die nicht Arbeit in diesem Fall der Fall ist.

Answer 1

versuchen, zu abstrahieren LINQtoSQL Einheiten hinter Schnittstellen

Ich habe einige schreckliche Erfahrungen gemacht. Es war eine Weile her, aber aus dem Gedächtnis des Hauptproblem war, dass es Verbände völlig bricht. wenn Sie ein Customer Zum Beispiel haben -> Order Beziehung, erhalten Sie es als ICustomer Belichtung auf, mit einer Sammlung von IOrders, was bedeutet, dass Customer etwas umständlich Mapping zu tun hat, werfen es interne Sammlung von Order Objekten als IOrders <. / p>

Dann muss man davon ausgehen, dass, wenn ein IOrder geben wird wieder an, dass wir es mit einem Order werfen können. Ansonsten LINQtoSQL kann nicht damit umgehen, aber dann, dass Niederlagen der Punkt, der die Schnittstelle dort in erster Linie mit.

Ich würde empfehlen, dass Sie nicht versuchen, und abstrahieren zu viel die Entitätsklassen, nicht LINQtoSQL nicht wirklich in ihnen keine wirkliche Magie setzen, die Datacontext behandelt ihre Ausdauer Lebenszyklus, so dass sie überprüfbar bleiben.

Die Aspekte, die ich hinter einer Schnittstelle zu verstecken würde genau die Wechselwirkungen mit Datacontext wären zum Beispiel Repository-Stil-Klassen:

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

Ihre Schnittstelle sollte modellieren, wie Sie für die Objekte möchten verwendet werden. Da Sie zu abstrahieren versuchen, dann sollten die Verbraucher haben nicht die DB abfragen. Ob Sie es eine Eigenschaft oder einen separaten Funktionsaufruf (dh GetPhones ()), ist ganz Sie überlassen. Da Sie völlig Dinge Verpackung sind, werden Sie einige Entscheidungen darüber, wie tief machen müssen / lazily wollen Sie Ihre Objekte laden.

Answer 3

Sie sollten Telefone Eigenschaft IUser hinzufügen und es auf NULL festlegbare machen, so dass für einen Benutzer, der das Telefon nicht haben, wird es null sein.

Da Sie nicht möchten, dass die Verbraucher über die API zu schreiben Anfragen, als Sie Funktionen wie GetUser implementieren sollten () .. etc.

Hier ist eine schöne Liste von Artikeln abt n-Tier-Anwendung in Asp.net

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

Answer 4

Ich neige dazu, die Linq2Sql verwandten Themen zu prüfen, eine Implementierung Detail des Datenzugriffscode zu sein und, wie die reale Struktur der Datenbank, sollte nicht unbedingt auf andere Teile des Systems ausgesetzt werden.

Wenn Ihr API von anderen Menschen verzehrt werden wird sollte es kohäsiv sein und einfach zu bedienen und nicht überladen durch die Dinge der Verbraucher muss nicht darüber wissen. Wenn ich mit den Nutzern und ihren Handys zu tun habe möchte ich nicht wirklich über Datacontexts oder (igitt) Datasets kennen.

Auch durch den Großteil Ihres Code nichts von der L2S halten und Datenbank finden Sie eine einfachere Zeit Testen haben, Schemaänderungen machen (oh, so dass nun die Benutzertabelle Bedürfnisse machte eine Geschichte jede Änderung zu halten) oder sogar zu ändern die ORM vollständig.