LINQ to SQL Entitäts- und Datenkontextklassen: Kapselung von Geschäftsobjekten

Question

Was sind Ihre bevorzugten Methoden, um LINQ to SQL-Entitätsklassen und Datenkontextklassen in Geschäftsobjekte zu kapseln?

Was haben Sie in einer bestimmten Situation für gut befunden?

Haben Sie bestimmte Muster erfunden oder übernommen?

Answer 1

Ich habe ein Muster gefunden, das meiner Meinung nach am besten funktioniert - zumindest in meinem Fall.

Ich erweitere Entitätsklassen mit Hilfe von Teilklassen. Ich verwende partielle Klassen, damit sich die Signatur der Entität nicht ändert (siehe die DeleteOnSubmit Aufruf im Delete Methode).

Ich habe ein kleines Beispiel gebastelt. Hier ist ein Bild der Datenbank und LINQ to SQL Klasse Setup:

Und hier ist die Teilklasse, in der ich die Geschäftslogik implementiere:

/// <summary>
/// This class extends BusinessLogicDataContext.Products entity class
/// </summary>
public partial class Product
{
    /// <summary>
    /// New up a product by column: dbo.Products.ProductId in database
    /// </summary>
    public Product(Int32 id)
    {
        var dc = new BusinessLogicDataContext();

        // query database for the product
        var query = (
            from p in dc.Products 
            where p.ProductId == id 
            select p
        ).FirstOrDefault();

        // if database-entry does not exist in database, exit
        if (query == null) return;

        /* if product exists, populate self (this._ProductId and
           this._ProductName are both auto-generated private
           variables of the entity class which corresponds to the
           auto-generated public properties: ProductId and ProductName) */
        this._ProductId = query.ProductId;
        this._ProductName = query.ProductName;
    }

    /// <summary>
    /// Delete product
    /// </summary>
    public void Delete()
    {
        // if self is not poulated, exit
        if (this._ProductId == 0) return;

        var dc = new BusinessLogicDataContext();

        // delete entry in database
        dc.Products.DeleteOnSubmit(this);
        dc.SubmitChanges();

        // reset self (you could implement IDisposable here)
        this._ProductId = 0;
        this._ProductName = "";
    }
}

Verwendung der implementierten Geschäftslogik:

// new up a product
var p = new Product(1); // p.ProductId: 1, p.ProductName: "A car"

// delete the product
p.Delete(); // p.ProductId: 0, p.ProductName: ""

Außerdem: LINQ to SQL Entity-Klassen sind von Natur aus sehr offen. Das bedeutet, dass die Eigenschaft, die der dbo.Products.ProductId Spalte sowohl einen Getter als auch einen Setter implementiert - dieses Feld sollte nicht veränderbar sein.

Meines Wissens kann man mit partiellen Klassen keine Eigenschaften überschreiben, daher implementiere ich in der Regel einen Manager, der das Objekt über eine Schnittstelle eingrenzt:

public interface IProduct
{
    Int32 ProductId { get; }

    void Delete();
}

Answer 2

Ich neige dazu, das Repository-Muster zu verwenden, um DataContexts zu kapseln.

Repository-Muster

Ich würde gerne einen besseren Weg finden, um POCO-Objekte aus meiner Datenschicht zu emittieren, während LINQ2SQL verwenden, obwohl.

Answer 3

Ich habe gerade ein Beispiel veröffentlicht, wie Sie Ihre Anwendung, die Linq to Sql für die Speicherung verwendet, mit IoC und T4-Templates strukturieren können.

http://daniel.wertheim.se/2010/03/14/linq-to-sql-how-to-separate-the-entities-and-the-datacontext/

Answer 4

Im Moment versuche ich, LINQ to SQL Entitätsklassen als Geschäftsobjekte zu verwenden, um sie zwischen Funktionen und Diensten weiterzugeben.

Natürlich sollten Sie separate Entitätsklassen für den Datenbankzugriff So können Sie das Layout Ihrer Datenbank ändern, ohne die Geschäftsobjekte zu verändern!

Ich wäre auch sehr an einer guten Lösung für dieses Problem interessiert!

Answer 5

Sehen Sie sich den Quellcode für die MVC-Beispielanwendung an, die Rob Conery zusammenstellt:

http://www.codeplex.com/mvcsamples/

Er hat eine separate Entitätsschicht, die den LINQ to SQL-Klassen zugeordnet ist.