ASP MVC: Sollten Dienste IQueryable zurückgeben?

Question

Was denkst du? sollte Ihr DAO ein IQueryable zurückgeben, um es in Ihren Controllern zu verwenden?

Answer 1

Im Moment klingt es attraktiv, aber really isn't.

Answer 2

Nein. Ihre Controller sollten keine komplexe Logik verarbeiten. Halte sie schlank. Das Model (nicht DAO) sollte dem Controller alles zurückgeben, was er benötigt, um auf die View zu gelangen.

Das Anzeigen von Abfragen (oder sogar Abfragen) in einer Controller-Klasse ist etwas, was ich als Code-Geruch betrachten würde.

Answer 3

Wenn Sie die "fette Modelle, dünne Controller" Paradigma dann nein folgen.

Siehe diesen Beitrag auf der Fat Controller anti-pattern.

Answer 4

Ich liebe die Weitergabe von IQueryable an meine Controller, da ich während der gesamten Lebensdauer meiner App-Entwicklung keine lahmen Paging- und Sortiermethoden in jeder einzelnen DAO-Methode und Schnittstelle erstellen muss.

GetCustomersByLastname(string lastname) 

wird schnell

GetCustomersByLastname(string lastname, string sortcolumn, int pagesize, int page) 

Immer wieder und immer wieder. Bleck!

Mit IQueryable können Sie Paging und Sortierung auf orthogonale Weise durchführen, z. B. indem Sie das IPagedList-Projekt nutzen. Durch die Rückgabe von IQueryable erhalten Sie außerdem einfachen Zugriff auf das gesamte Objekt .Count() ohne mehr Perversion Ihrer Datenschicht.

@ Roberts Argument von IQueryable entspricht fetten Controllern ist sehr wackelig. Ein Fat Controller wäre den aufgeblähten .aspx.cs Seiten von früher ähnlich. Wenn alles, was du tust, sich mit deiner DAL verbindet und dann die Ergebnisse von dir versendst, erhältst du keine "Fettigkeit" von deiner Abfragetechnik, du erhältst es von viel Logik innerhalb einer einzigen Klasse. Sie erhalten keinen Fat Controller aufgrund Ihrer Datenzugriffsmethoden, es sei denn, Sie beginnen mit der Protokollierung, Benachrichtigungen und anderen orthogonalen Problemen.

public ActionResult Detail(string searchTerm) 
{ 
    var model = MyDAL.MyObjects(searchTerm); 
} 

vs:

public ActionResult Detail(string searchTerm) 
{ 
    var model = MyDAL.MyObjects.Where(x => x.Name == searchTerm); 
} 

Ich sehe keinen zwingenden Unterschied.

@Mark Seemanns Antwort ist gleichermaßen wackelig. Sicher, Sie können Ihre gesamte Datenschicht in der Mitte eines Projekts ändern, aber das wird ein komplexes Desaster sein, egal wie abstrahiert Sie sind. Das von ihm verwendete Beispiel ist der Wechsel von Linq2Sql in den Tabellenspeicher von Windows Azure. RDBMS zu Schlüssel/Wert speichern? Und der Schwachpunkt ist Ihre Repository-Implementierung? Von RDBMS zu einem Key/Value Store zu gehen, wird eine Verrücktheit sein, die schrecklich wird, egal was passiert.

Mark bringt auch Domain Driven Design in seinem Argument. Ist das die Art von System Ihres Gebäudes? Gibt es genug "Domain" statt reine CRUD-Szenarien, die diesen Ansatz wertvoll machen? Wenn nicht, warum?

Die Verwendung von LINQ und der IQueryable-Schnittstelle verringert den Aufwand beim Datenschichtwechsel. Wenn Sie zwischen ORMs wechseln, die LINQ und IQueryableProvider unterstützen (ich denke, das ist der Name), interessiert sich nur der Downstream-Code für diese Änderung. Ihre Controller würden von den meisten auf dem Markt befindlichen ORMs unverändert bleiben.