0

Dies betrifft eine Unternehmensanwendung mit einer sehr allgemeinen Datenbank (alle Objekte werden mithilfe von Daten in der Datenbank identifiziert und internationalisiert/globalisiert/lokalisiert).ASP.NET MVC - Modellentscheidung: Wie gestaltet man es?

  • Erstellen Sie ein Modell für das Repository-Muster, machen Sie dann ein anderes Modell für den DB-Zugriff (LINQ2SQL oder EF) (generieren Sie 1: 1) und verwenden Sie die spätere Datenzugriffsebene des Repository-Modells?
  • Verwenden Sie einfach das L2S/EF/NHibernate-Modell direkt, Mapping-Modell zu DB und Öffnen der Persistenzschicht?
  • Werden diese Doppelmodell-Idee (Repository-Muster) Popup-Probleme, die dynamisch stapelbare LINQ-Suchabfragen ermöglichen, wenn Sie das L2S/EF-Modell direkt in einer dualen Modellumgebung verwenden?

    Bitte beraten.

    Antwort

    0

    Solange Sie IQueryable-Objekte in Ihrem Repository verfügbar machen, sollten Sie keine Probleme haben, Abfragen in der von Ihnen vorgeschlagenen Weise zu stapeln.

    Ich wäre vorsichtig bei der Verwendung von Entity Framework für diese, da Lazy Loading nicht in der Art unterstützt wird, wie Sie erwarten könnten. Linq to SQL wird das problemlose Laden ohne Probleme handhaben.

    Weitere Informationen zu träges Laden im Rahmen Entity finden Sie unter:
    http://www.singingeels.com/Articles/Entity_Framework_and_Lazy_Loading.aspx

    +0

    Ich kenne EF Vorteile und Nachteile, da ich es erforscht habe und Artikel darüber geschrieben habe. Ich erwähne EF als eine Lösung, bei der EF ein funktionierendes Modell für die Geschäftslogik sein würde. – BuzzBubba

    +0

    Meiner Meinung nach sollten Sie eine separate Ebene für die Geschäftslogik erstellen, es sei denn, EF verfügt über integrierte Hooks. –

    +0

    Also, Sie denken, ich sollte ein Modell für alle meine Geschäftsobjekte mit Model-First-Ansatz machen, dann EF-Designer verwenden, um ein neues Modell zu generieren und die beiden Trog-Methoden der Klassen des Geschäftsmodells zu verknüpfen? - z.B. wie "Account" und "Accounts" -Klassen und "EFAccount" (EF generierte Entity-Matchingtabelle "TAccount"), wo Accounts eine Methode GetAccount (int id) haben würden, die "Account" zurückgibt, aber intern "Account" generierte "EFAccount" und einige seiner Eigenschaften durch eine LINQ-Abfrage? - (Ich hoffe, ich bin hier klar genug) – BuzzBubba

    0

    Werfen Sie einen Blick auf sharp architecture.

    In Bezug auf die Rückgabe von IQueryable aus Ihren Repository-Objekten, ist es meiner Meinung nach, dass so eine klare Trennung von Bedenken in Ihrer Anwendung verwischt. Ich bin für die Arbeit mit IQueryable innerhalb Ihrer Datenzugriffsschicht, aber sobald Sie anfangen, Objekte als IQueryable zurückzugeben, bieten Sie die Möglichkeit für Ihre Controller und/oder Ansichten, sich mit dem Datenzugriff zu befassen. Dies kann sich sogar negativ auf die Testbarkeit Ihrer Anwendung auswirken.

    +0

    Ich verstehe die Sorge. – BuzzBubba