Spicefactory - Teil 1: Würzen Sie mit Petersilie, Zimt und Piment

In meinem Artikel auf InfoQ habe ich untersucht, wie Grails und Flex kombiniert werden können, um eine Plattform für die schnelle Anwendungsentwicklung zu schaffen. Meiner Meinung nach ist dies derzeit eine der vielversprechendsten Kombinationen für die RIA-Entwicklung. Im Flex-Bereich ist viel los und es gibt viele Initiativen. Vor ein paar Tagen bin ich im Internet auf diese Initiative gestoßen: spicefactory.org. Abgesehen von dem lustigen Namen halte ich sie für eine sehr interessante Initiative, da sie einige neue Konzepte in den Flex-Remoting-Mix einbringt.

Parsley Dies ist eine IOC-Implementierung, die vom Spring-Framework inspiriert ist. Auf der offiziellen Website wird es mit Cairngorm verglichen. Ohne es überhaupt ausprobiert zu haben, glaube ich, dass es mir schon besser gefällt als Cairngorm. Für mich ist Cairngorm ein Haufen sehr guter Ideen, die kaum implementiert wurden, um sie zu unterstützen. Parsley ist, wie Spring, eher ein Haufen guter Ideen mit einer Implementierung, die sie unterstützt. Zu testen, wie dies tatsächlich funktioniert, steht ganz oben auf meiner ToDo-Liste. Zimt Dies ist ein Remoting-Framework, das vollständig auf AS3 und Java basiert. Es werden keine Flex-Klassen verwendet. Es verwendet jedoch AMF, die schnelle Serialisierungstechnologie für AS-Objekte. Außerdem verwendet es ein Servlet für die Kommunikation mit der Server-Seite. Beim Lesen der Dokumentation habe ich mich gefragt, warum dies besser sein soll als die Verwendung des Remoting-Dienstes von Flex. Ich denke, wenn Sie SWF ohne Flex verwenden, ist dies eine gute Wahl.Dennoch habe ich versucht, meine Grails-Dienste mit diesem Framework zu veröffentlichen. Dies sollte mit Hilfe eines benutzerdefinierten Konfigurationsprozessors möglich sein. Bei der Implementierung stieß ich auf das Problem, dass Cinnamon von Ihrem Dienst verlangt, dass er eine Schnittstelle implementiert. Da Grails-Dienste nur über eine Implementierung verfügen, ist mein Versuch hier gescheitert. Piment Dies ist etwas völlig anderes: Pimento bietet die Möglichkeit, den JPA EntityManager direkt aus dem clientseitigen Code zu verwenden. Sie können also aus Ihrer Flex-Anwendung heraus mit JPA Daten aus der Datenbank laden, abfragen und manipulieren. Für mich hört sich das... interessant an.Wenn es richtig konfiguriert ist, um mit Grails zusammenzuarbeiten, was ich im nächsten Blog behandeln werde, wird eine Anwendung zur Datenmanipulation mit Flex recht trivial. Nehmen wir an, wir haben die folgende Domänenklasse in Grails:

import org.spicefactory.pimento.config.Operation;
@org.spicefactory.pimento.config.Managed(operations=[Operation.ALL])
class Person {
  def String name;
  def int Alter;
}

Dies ist eine ganz normale Grails-Domänenklasse, mit der Ausnahme, dass sie eine Annotation hat, die Pimento so konfiguriert, dass Datenmanipulationen an dieser Klasse möglich sind. Diese Klasse wird im clientseitigen Code wie folgt gespiegelt:

Paket
{
    [RemoteClass(alias='Person')]
  public class Person
  {
  public var id:Number = 0;
  public var version:Number;
  public var name:String;
  public var age:Number;
  }
}

Das Duplizieren dieser Klasse ist immer noch notwendig. Es sollte recht einfach sein, diese Klasse aus Groovy-Code zu erzeugen. Beachten Sie, dass die Felder id und version, die von Grails automatisch hinzugefügt werden, auch in die ActionScript-Klasse kopiert werden. Der Rest der Client-Seite könnte etwa so aussehen:

private function initEntityManager () : void {
  var config:PimentoConfig = new PimentoConfig();
  config.serviceUrl = getWebContextRoot(application.url) + "service";
  trace('url: ' + config.serviceUrl)
  config.defaultTimeout = 5000;
  config.configure();
  entityManager = config.entityManager;
}
private var entityManager:EntityManager;
[Bindbar]
private var people:ArrayCollection;
private function refreshPersons () : void {
  var q:Query = entityManager.createQuery("from Person where age between :minAge and :maxAge");
  q.setNamedParameter("minAge", uint(ageFilter.values[0]));
  q.setNamedParameter("maxAge", uint(ageFilter.values[1]));
  q.getResultList().addResultHandler(onRefresh);
}
private function onRefresh (result:Array) : void {
  this.people = new ArrayCollection(result);
}

Sehen Sie, wie der Client die Daten direkt aus dem EntityManager lädt! Ebenso kann der Client Daten direkt aktualisieren und löschen. Was halten Sie nun von diesem Ansatz? Auf der PRO-Seite:

1. Viel weniger Code schreiben: Keine DAO erforderlich. Keine Serviceschicht, die nur an die DAOs delegiert.
2. Keine Probleme mit trägem Laden: Der Client hat die Kontrolle und kann laden, was nötig ist.
3. Besseres Verpacken von Funktionen: Der gesamte (oder der meiste) Code, der für eine Funktion erforderlich ist, befindet sich im Client-Code.
4. ...

Auf der CON-Seite:

1. Sehr grobe Zugriffskontrolle: Operationen können pro Entität erlaubt/verboten werden.
2. Datenzugriffscode (obwohl EJBQL) verstreut im (Client-)Code.
3. Keine klare Trennung der Anliegen: Sehr datenzentrierte und datengesteuerte Anwendung.
4. ...

Haben Sie eine Idee?