Grails: Dienste gegen Groovy -Klassen

Question

Dokumentation heißt:

Das Grails-Team entmutigt die Einbettung der Kernanwendungslogik in Controller, da es keine Wiederverwendung und eine saubere Trennung von Bedenken fördert.

Ich habe einen API -Controller und ein paar Groovy -Klassen im SRC/Groovy -Ordner. Diese Klassen implementieren nur meine Anwendungslogik, sodass Aktionen im API -Controller auf diese Weise funktioniert:

//index page
def index = {
    render new IndexApi().index(params) as JSON
}

Ich bin neugierig - gibt es einen Grund, meine Anwendungslogik aus einfachen Groovy -Klassen in Dienste zu verschieben?

Answer 1

Wenn Sie Transaktionsverhalten möchten, sollten Sie Ihre Logik in die Dienste einfügen. Sonst müssten Sie sich selbst darum kümmern, was nicht im Geiste der Verwendung von Gral ist.

Da ich selbst kein Grails -Experte bin, stellte ich meine "nicht transaktionalen" Klassen außerhalb der Serviceschicht, wie Builder -Klassen, Helfer und andere Logik, die nicht transaktional, sondern aus der Serviceschicht verwendet werden.

Answer 2

Tatsächlich geht es bei Diensten nicht nur um Transaktionen. Services eignen sich hervorragend für injizierbare Singleton-Komponenten mit Nullkonfiguration. Sie können ohne Neustart der Vollgründungsumgebung neu geladen werden.

Answer 3

Es gibt drei Gründe:

1. Es erleichtert den Controller kleiner -> leichter zu verstehen und zu warten

2. Es erleichtert es logisch zu testen.

3. Sie möchten Ihre Transaktionen wirklich nicht manuell verwalten.

Wenn Sie alles in den Controller einfügen würden, müssten Sie die Web -Laufzeit erstellen, um einen Test auszuführen. Wenn Ihre Logik draußen ist, können Sie die Daten, die Sie benötigen, aus der HTTP -Anforderung und allen anderen Quellen kopieren und einfach den Code aufrufen. Die Logik hängt also nicht von HTTP -Sitzungen, Anfragen oder anderen anderen ab, die Sie nicht möchten.

Zum Beispiel zum Testen von JSPs benötigen Sie eine httprequest. Für eine Anfrage benötigen Sie eine HTTPSession und einen JSPWriter. Diese brauchen einen Sitzungskontext. Um einen einzigen Test auszuführen, müssen Sie eine ganze Reihe von Klassen einrichten und initialisieren. Und all dies sind Schnittstellen und die Implementierungen sind privat. Sie müssen also die tatsächlichen Methoden (alle 300) selbst implementieren. Und Sie verstehen das besser oder Ihre Tests werden nicht testen, was Sie wollen.