Wie verwende ich LINQ To SQL in einer N-Tier-Lösung?

Question

Nun, da LINQ to SQL ein ist wenig Wenn ich ausgereifter bin, würde ich gerne wissen, welche Techniken die Leute verwenden, um mithilfe der Technologie eine n-stufige Lösung zu erstellen, da mir das nicht so offensichtlich erscheint.

Answer 1

LINQ to SQL hat nicht wirklich eine N-Tier-Story, die ich gesehen habe, da die Objekte, die es erstellt, zusammen mit dem Rest in der Klasse erstellt werden, sodass Sie nicht wirklich über eine Assembly verfügen, auf die Sie gut verweisen können so etwas wie Webdienste usw.

Die einzige Möglichkeit, die ich wirklich in Betracht ziehen würde, besteht darin, den Datenkontext zum Abrufen von Daten zu verwenden, dann ein zwischengeschaltetes Datenmodell zu füllen, dieses durchzuleiten und auf beiden Seiten darauf zu verweisen und es auf Ihrer Client-Seite zu verwenden – sie dann zurückzugeben und zu pushen Daten zurück in einen neuen Datenkontext oder intelligente Aktualisierung von Zeilen, nachdem Sie sie erneut abgerufen haben.

Vorausgesetzt, ich verstehe, worauf Sie hinaus wollen :\

Ich habe ScottGu in seinem Blog die gleiche Frage gestellt, als ich anfing, mich damit zu befassen – aber ich habe kein einziges Szenario oder keine einzige App in freier Wildbahn gesehen, die LINQ to SQL auf diese Weise verwendet.Websites wie Rob Connerys Storefront sind näher am Anbieter.

Answer 2

Hm, Rockford Lhotka Schade, dass LINQ to SQL eine wunderbare Technologie zum Abrufen von Daten aus einer Datenbank ist.Er schlägt vor, dass sie anschließend gebunden werden müssen, um „Domänenobjekte zu erreichen“ (auch bekannt als „Reach Domain Objects“).CSLA-Objekte).

Im Ernst, LINQ to SQL unterstützt die N-Tier-Architektur DataContext.Update Methode.

Answer 3

Vielleicht möchten Sie einen Blick darauf werfen ADO .Net Entity Framework als Alternative zu LINQ to SQL, obwohl es auch LINQ unterstützt.Ich glaube, dass LINQ to SQL relativ leichtgewichtig und einfach gestaltet ist, während das Entity Framework anspruchsvoller ist und wahrscheinlich besser für große Unternehmensanwendungen geeignet ist.

Answer 4

OK, ich werde mir eine mögliche Lösung nennen.

Einfügungen/Updates waren nie ein Problem;Sie können die Geschäftslogik in eine Save/Update-Methode einbinden;z.B.

public class EmployeesDAL
{
    ...
    SaveEmployee(Employee employee)
    {
        //data formatting
        employee.FirstName = employee.FirstName.Trim();
        employee.LastName = employee.LastName.Trim();

        //business rules
        if(employee.FirstName.Length > 0 && employee.LastName.Length > 0)
        {
            MyCompanyContext context = new MyCompanyContext();

            //insert
            if(employee.empid == 0)
             context.Employees.InsertOnSubmit(employee);
            else
            {
              //update goes here
            }

            context.SubmitChanges();


        }
        else 
          throw new BusinessRuleException("Employees must have first and last names");
     }
 }

Zum Abrufen von Daten oder zumindest zum Abrufen von Daten, die aus mehr als einer Tabelle stammen, können Sie gespeicherte Prozeduren oder Ansichten verwenden, da die Ergebnisse nicht anonym sind und Sie sie von einer externen Methode zurückgeben können.Verwenden Sie beispielsweise eine gespeicherte Prozedur:

    public ISingleResult<GetEmployeesAndManagersResult> LoadEmployeesAndManagers()
    {
        MyCompanyContext context = new MyCompanyContext();

        var emps = context.GetEmployeesAndManagers();

        return emps;
    }

Answer 5

Im Ernst, LINQ to SQL hatte seine Unterstützung für die n-Tier-Architektur, siehe DataContext.Update-Methode

Einiges von dem, was ich gelesen habe, deutet darauf hin, dass die Geschäftslogik den DataContext umschließt – mit anderen Worten: Sie umschließen das Update auf die von Ihnen vorgeschlagene Weise.

So wie ich traditionell Geschäftsobjekte schreibe, kapsele ich normalerweise auch die „Lademethoden“ im BO;Ich könnte also eine Methode namens LoadEmployeesAndManagers haben, die eine Liste von Mitarbeitern und ihren unmittelbaren Vorgesetzten zurückgibt (dies ist ein erfundenes Beispiel).Vielleicht liegt es nur an mir, aber in meinem Frontend würde ich lieber e.LoadEmployeesAndManagers() sehen als eine lange LINQ-Anweisung.

Wie auch immer, mit LINQ würde es wahrscheinlich so aussehen (nicht auf Syntaxkorrektheit überprüft):

var emps = from e in Employees
                join m in Employees
                on e.ManagerEmpID equals m.EmpID
                select new
                          { e,
                            m.FullName
                          };

Wenn ich die Dinge nun richtig verstehe, wenn ich dies beispielsweise in eine Klassenbibliothek einfüge und es von meinem Frontend aus aufrufe, kann ich dies nur als IEnumerable zurückgeben, sodass ich meine starke typisierte Güte verliere.Die einzige Möglichkeit, ein stark typisiertes Objekt zurückzugeben, wäre, meine eigene Employees-Klasse (plus ein Zeichenfolgenfeld für den Managernamen) zu erstellen, sie aus den Ergebnissen meiner LINQ to SQL-Anweisung zu füllen und diese dann zurückzugeben.Aber das scheint kontraintuitiv zu sein ...Was genau hat mir LINQ to SQL gebracht, wenn ich das alles tun muss?

Ich glaube, dass ich die Dinge vielleicht aus der falschen Perspektive betrachte;Für jede Aufklärung wäre ich dankbar.

Answer 6

„Die einzige Möglichkeit, dies zurückzugeben, ist als IEnumerable, sodass ich meine starke typisierte Güte verliere.“

das ist falsch.Tatsächlich ist Ihre Abfrage stark typisiert, es handelt sich lediglich um einen anonymen Typ.Ich denke, die von Ihnen gewünschte Abfrage sieht eher so aus:

var emps = from e in Employees
            join m in Employees
            on e.ManagerEmpID equals m.EmpID
            select new Employee
                      { e,
                        m.FullName
                      };

Was IEnumerable zurückgibt.

Hier ist ein Artikel Ich habe zu dem Thema geschrieben.

Linq-to-SQL ist ein ORM.Es hat keinen Einfluss auf die Art und Weise, wie Sie eine N-Tier-Anwendung entwerfen.Sie verwenden es auf die gleiche Weise wie jedes andere ORM.

Answer 7

@liammclennan

Was IEnumerable zurückgibt....Linq-to-SQL ist ein ORM.Es hat keinen Einfluss auf die Art und Weise, wie Sie eine N-Tier-Anwendung entwerfen.Sie verwenden es auf die gleiche Weise wie jedes andere ORM.

Dann bin ich wohl immer noch verwirrt.Ja, Linq-to-Sql ist ein ORM;aber soweit ich das beurteilen kann, übersäte ich meinen Front-End-Code immer noch mit Inline-SQL-Anweisungen (Linq, nicht SQL ...)aber dennoch bin ich der Meinung, dass dies vom Frontend weg abstrahiert werden sollte).

Angenommen, ich verbinde die LINQ-Anweisung, die wir als Beispiel verwendet haben, in einer Methode.Soweit ich das beurteilen kann, kann ich es nur so zurückgeben:

public class EmployeesDAL
{
    public IEnumerable LoadEmployeesAndManagers()
    {
            MyCompanyContext context = new MyCompanyContext();

            var emps = from e in context.Employees
            join m in context.Employees
            on e.ManagerEmpID equals m.EmpID
            select new
                      { e,
                        m.FullName
                      };

            return emps;
    }

}

Von meinem Frontend-Code aus würde ich etwa Folgendes tun:

EmployeesDAL dal = new EmployeesDAL;
var emps = dal.LoadEmployeesAndManagers();

Dies gibt natürlich ein IEnumerable zurück;aber ich kann dies nicht wie jedes andere ORM verwenden, wie Sie sagen (es sei denn natürlich, ich verstehe es falsch), weil ich das nicht tun kann (auch dies ist ein erfundenes Beispiel):

txtEmployeeName.Text = emps[0].FullName

Das habe ich mit "Ich verliere stark getippte Güte". Ich denke, ich stimme dem Tiegel zu;dass LINQ-to-SQL nicht für diese Verwendung konzipiert wurde.Auch hier gilt: Wenn ich die Dinge nicht richtig sehe, zeigt mir jemand den Weg :)