Wo verschmelzen Objekte Daten in einem 3-stufigen Modell?

Question

Es ist wahrscheinlich ein einfaches 3-stufiges Problem. Ich möchte nur sicherstellen, dass wir die Best Practice dafür verwenden, und ich bin noch nicht so familiär mit den Strukturen.

Wir haben die 3 Ebenen:

• GUI: ASP.NET für Präsentationsschicht (erste Plattform)
• BAL: Business-Layer wird die Logik eines Webservers in C#bearbeiten, sodass wir sie beide für WebForms/MVC + Webservices verwenden können
• DAL: LINQ zu SQL in der Datenschicht, Rückgabe von BusinessObjects nicht linq.
• DB: Der SQL wird Microsoft SQL-Server/Express sein (noch nicht entschieden).

Denken wir an Setup, wo wir eine Datenbank von [Personen] haben. Sie können alle mehrere [Adresse] haben und wir haben eine vollständige Liste aller [Postalcode] und entsprechenden Stadtnamen usw.

Der Deal ist, dass wir uns vielen Details aus anderen Tischen angeschlossen haben.

{Relations}/[Tabellen

• Person]: 1 --- n: {PersonAddress}: m --- 1: [Adresse
• Adresse]: n --- 1: [Postalcode

Jetzt wollen wir den Dal für Person bauen. Wie sollte der Personbo aussehen und wann treten die Anschlüsse auf? Ist es ein Geschäftslayer-Problem, alle CityNames und mögliche Adressen PR zu holen? Person? Oder sollte der Dal all dies vervollständigen, bevor er das Personbo zum BAL zurückgibt?

Class PersonBO 
{
    public int ID {get;set;}
    public string Name {get;set;}
    public List<AddressBO> {get;set;} // Question #1
} 

// Q1: Rufen wir die Objekte vor, bevor wir das Persono zurückgeben, und sollte es stattdessen ein Array sein? Oder ist das völlig falsch für N-Tier/3-Tier?

Class AddressBO 
{
    public int ID {get;set;}
    public string StreetName {get;set;}
    public int PostalCode {get;set;} // Question #2
} 

// F2: Führen wir die Suche oder verlassen wir einfach den Postalcode für eine spätere Suche?

Kann jemand erklären, in welcher Reihenfolge, um welche Objekte zu ziehen, zu ziehen? Konstruktive Kritik ist sehr willkommen. :Ö)

Answer 1

Sie erfinden das Rad neu; Orms lösen bereits das meiste Problem für Sie und Sie werden es ein wenig schwierig finden, selbst zu tun.

Die Art und Weise, wie ORMs wie Linq zu SQL, Entity Framework und Nhibernate dies tun, ist eine Technik genannt faules Laden von Assoziationen (die optional mit einer eifrigen Belastung überschrieben werden können).

Wenn Sie a hochziehen Person, es lädt die nicht Address bis Sie können auch pro-quer angeben, dass Sie die möchten Address geladen werden für jeder Person (eifrige Last).

In gewissem Sinne fragen Sie sich im Grunde genommen, ob Sie faul oder eifrig von dem ausführen sollten oder nicht AddressBO für die PersonBO, und die Antwort lautet: weder. Es gibt keinen einzigen Ansatz, der universell funktioniert. Standardmäßig Sie sollten wahrscheinlich faul laden, damit Sie nicht viel unnötige Zusammenhänge machen. Um dies zu schaffen, müssen Sie Ihre bauen PersonBO mit einem faulladenden Mechanismus, der einen Hinweis auf den Dal beibehält. Sie möchten jedoch immer noch die Möglichkeit haben, eifrig zu laden, die Sie in Ihre "Business-Access" -Logik einbauen müssen.

Eine weitere Option, wenn Sie einen hochkundenspezifischen Datensatz mit spezifischen Eigenschaften aus vielen verschiedenen Tabellen zurückgeben müssen, besteht darin, A nicht zurückzugeben PersonBO überhaupt, aber stattdessen a Datenübertragungsobjekt (Dto). Wenn Sie einen Standardmechanismus für faulen Ladungen implementieren, können Sie dies manchmal als eifrige Lastversion ersetzen.

---

Zu Ihrer Information, faule Lader in Datenzugriffs -Frameworks werden normalerweise mit der Ladelogik in der Assoziation selbst erstellt:

public class PersonBO
{
    public int ID { get; set; }
    public string Name { get; set; }
    public IList<AddressBO> Addresses { get; set; }
}

Dies ist nur ein Poco, die Magie findet in der tatsächlichen Listenimplementierung statt:

// NOT A PRODUCTION-READY IMPLEMENTATION - DO NOT USE

internal class LazyLoadList<T> : IList<T>
{
    private IQueryable<T> query;
    private List<T> items;

    public LazyLoadList(IQueryable<T> query)
    {
        if (query == null)
            throw new ArgumentNullException("query");
        this.query = query;
    }

    private void Materialize()
    {
        if (items == null)
            items = query.ToList();
    }

    public void Add(T item)
    {
        Materialize();
        items.Add(item);
    }

    // Etc.
}

(Dies ist offensichtlich keine Produktionsqualität, sondern nur um die Technik zu demonstrieren. Sie beginnen mit einer Abfrage und materialisieren die tatsächliche Liste erst, bis Sie müssen.)