Scala Play vs. ASP.NET Web API – Web-Frameworks im Vergleich

Unser Unternehmen entwickelt seit mehr als 12 Jahren Software. Und etwa die Hälfte unserer Projekte sind hochbelastete verteilte Multi-Thread-Systeme. Daher verwenden unsere Entwickler dabei modernste Technologien und neueste Frameworks.

In diesem Artikel werden wir uns auf zwei aktuelle Frameworks konzentrieren, Play und ASP.NET Web API.

Play-Framework

In letzter Zeit wurde dem Play Framework 2.x viel Aufmerksamkeit geschenkt. Es ist bereits drei Jahre her, dass Redwerk Play erstmals für Java implementiert hat. Da wir viel Erfahrung mit Play haben, werden wir versuchen, Ihnen einen kurzen, aber umfassenden Überblick über alle Vorteile dieses Frameworks zu geben.

Die Entwickler von Play beschreiben ihr Framework mit einem Satz: „The High Velocity Web Framework For Java and Scala“. Heute wird dieses Framework als Full Stack betrachtet und besteht aus mehreren „Schichten“.

Tools für Deployment und Abhängigkeitsmanagement

Genau wie Django, Ruby on Rails und andere multifunktionale Frameworks verfügt Play über eine Reihe von Dienstprogrammen, die in TypeSafe Activator, einem Dienst für die Verwaltung und Erstellung von reaktiven Anwendungen, zusammengefasst sind. Activator umfasst ein einfaches Build-Tool, eine Schnellstart-GUI und einen Katalog mit vorgefertigten Anwendungsvorlagen.

Seine Hauptmerkmale sind:

• Inkrementelle Kompilierung
• Eingebautes Code-Dokumentationssystem
• Vorlagen- und Plugin-System
• Eingebauter Webserver für die Entwicklung
• Umfangreiche Debugging-Funktionalität
• Ausgezeichnetes Framework für die Erstellung von Specs2-Unit-Tests
• Volle Unterstützung der Entwicklung von RESTful Services
• Verwaltungssystem für Code-Abhängigkeiten
• Integration mit führenden IDE

Wir möchten auch auf die Möglichkeit hinweisen, in der Konfigurationsversion von Activator und Scala die automatische Aktualisierung für ausgewählte Plugins einzustellen, sowie auf die große Vielfalt der verfügbaren Plugins. Sowohl Scala als auch Play arbeiten auf der Java-Plattform, so dass alle externen Abhängigkeiten aus einem Standard-Maven-Repository gezogen werden. Natürlich können Sie auch eigene Repositories hinzufügen.

HTTP-Netty-Server

Die Play-Entwickler verwenden nicht mehr das JEE-Modell zusammen mit Servlets, sondern entscheiden sich für Netty, einen fortschrittlichen NIO-Netzwerkserver. Infolgedessen stellt Play eine Webebene dar, die den Zustand nicht speichert oder teilt (zustandslose Webebene), was für hochbelastete Multithreading-Webdienste sehr wichtig ist. Außerdem unterstützt das Framework die neuesten Technologien wie Non-blocking I/O und Echtzeit-Kommunikation (Websockets, EventSource, Comet). Darüber hinaus bietet Play sehr flexible Konfigurationsoptionen wie Thread-Pools, eine Anzahl von Workern und Parallelitätsfaktoren.

Wir möchten auch darauf hinweisen, dass Play ein komplettes Toolset für die Erstellung reaktiver Anwendungen mit dem Akka-Framework darstellt, das auf dem Green-Thread-Konzept aufbaut und Actor- und Future-Begriffe im Kern hat. Aus diesem Grund ist ein ganzes Kapitel der Dokumentation der Methode der nicht-blockierenden Code-Entwicklung gewidmet. Es gibt Beschreibungen der wichtigsten Fälle, in denen Code blockiert wird, wie z.B. DB, 3d-Party-API-Anfragen, Arbeit mit Dateien und CPU-intensive Operationen. Dies soll Entwicklern helfen, die Verwendung von blockierendem Code in ihren Projekten zu minimieren.

Datenmodell

OOB Play hat ein eingebautes ORM-Framework EBean. Wir haben es in unseren Projekten mehrfach eingesetzt und waren mit den Ergebnissen sehr zufrieden. Es ist viel einfacher als JPA und seine Realisierungen wie Hibernate, sowohl beim Lernen als auch bei der Entwicklung. Außerdem verfügt Play über einen eingebauten Mechanismus zur Migration des DB-Schemas „Evolutions“, der sich als fantastische Lösung erwiesen hat. In einer App überwacht es automatisch den Ordner conf/evolutions/ hinsichtlich neuer Skripte des DB-Upgrade-Downgrade-Schemas (*.sql-Dateien). Wenn eine neue Evolution erkannt wird, fragt das Framework den Entwickler, ob eine neue Evolution aufgerollt werden soll oder nicht. Damit das Evolutionsskript funktioniert, muss der Entwickler nur auf „Skript anwenden“ klicken. Alle oben genannten Punkte gewährleisten die Gültigkeit der Daten und die Übereinstimmung zwischen Code und Datenmodell. Dies ist von größter Bedeutung, da die moderne Entwicklung normalerweise in mehreren Zweigen stattfindet und man sehr oft zwischen ihnen wechseln muss.

Beachten Sie, dass Sie dank der Modulstruktur problemlos externe ORM-Frameworks wie Slick verwenden können, die als DB-Bibliothek für Scala sehr empfehlenswert ist. Slick ist ein fantastisches Framework, da es anstelle von HSQL-Anfragen oder tonnenweise Annotationen für die Arbeit mit der DB. Es verwendet nativen Scala-Code. So ist eine Auswahl aus der DB mit Filtern ähnlich wie der Code, der mit einer einfachen Sammlung wie List oder Map arbeitet. Weitere Details über Slick finden Sie in der offiziellen Dokumentation hier

Play Web API

When we first started using Play Web API, we expected to see a great variety of filters, tons of annotations, complex routing, XML configs and exceptions with many Als wir anfingen, die Play Web API zu verwenden, erwarteten wir eine große Vielfalt an Filtern, tonnenweise Annotationen, komplexes Routing, XML-Konfigurationen und Ausnahmen mit vielen unnötigen Zeilen wie in Spring Framework. Aber zu unserer Freude war alles ganz anders. Lassen Sie all Ihre Sorgen hinter sich, denn das gehört jetzt alles der Vergangenheit an.

Das Wichtigste zuerst – Play Framework 2.x ist in der Programmiersprache Scala geschrieben, was bereits ein großer Schritt ist. Werfen Sie einfach einen Blick auf die umfangreiche Liste der Unternehmen, die Scala in der Produktionsumgebung einsetzen.

Der Kern von Play basiert auf zwei anderen innovativen Frameworks: Akka Actors und Netty Network Stack. Beide Entwickler halten sich an den funktionalen Entwicklungsstil und führende Techniken wie Zustandsunveränderlichkeit, Ereignisschleifen, Nachrichtenübermittlung, Verhaltenskomposition und Funktionen erster Klasse. Aus diesem Grund ist Play eines der fortschrittlichsten Frameworks dank seiner Funktionen und Betriebsgeschwindigkeit.

Der Routen-Mechanismus in Play ist recht einfach, aber von höchster Qualität. Alle Routen werden in einer conf/routes-Datei gesammelt. Das Konfigurationsformat ist wie folgt: Controller und seine Methode, URL, an die er gebunden ist, und eine Liste der erforderlichen Parameter mit ihren Datentypen. Sie können auch unnötige Parameter angeben.

Play Scala-Vorlagen. Die Entwickler von Play haben keine eigene Sprache für Vorlagen oder Tag-Bibliotheken entwickelt. Dies ermöglichte es ihnen, Scala-Vorlagen zu verstehen und bei der Entwicklung von responsiven HTML-Seiten zu verwenden. Die allgemeinen Prinzipien wurden von der ASP.NET Razor-Technologie übernommen. Wir neigen zu der Ansicht, dass es besser ist, einen deklarativen Ansatz für die Entwicklung von Code für die Ansicht zu verwenden. Aber wir müssen zugeben, dass die Scala Templates Engine mit leistungsstarken und flexiblen Lösungen wie Blöcken, impliziter Formularfelddekoration und View-Kompositionen ausgestattet ist.

Es ist auch erwähnenswert, dass OOB Play JSON- und XML-Inhalte unterstützt. Die JSON-Unterstützung wurde mit der Jackson-Bibliothek realisiert. Es ist wichtig, dass die XML-Unterstützung nicht so groß ist wie die von Spring MVC, so dass Sie externe Bibliotheken verwenden müssen. Das XML-Format wird nur selten für die Kommunikation in neuen Projekten verwendet, und die Daten werden in JSON serialisiert / de-serialisiert.

Unter Berücksichtigung aller oben genannten Aspekte kann Play als nahezu perfekter Kandidat für die Entwicklung eines REST-API-Dienstes, eines kleinen Portals oder eines hochbelasteten Webdienstes bezeichnet werden. Im letzteren Fall können Sie immer Akka Cluster und die erforderliche Anzahl von GCD für die Aufrechterhaltung des Datenverkehrs verwenden.

Wir glauben, dass die Vorteile wie folgt sind:

• Einfaches RESTful-Framework
• Modulstruktur mit der Möglichkeit einer einfachen Verwaltung von Abhängigkeiten
• Verschiedene OOB-Möglichkeiten: ORM, Job Scheduler, Validierung, SMTP-Mail, JSON- und XML-Unterstützung, DB-Evolution-Unterstützung, automatischer Datei-Upload, SSL-Unterstützung, etc.
• Eingebautes Framework für Tests
• Vollständige Unterstützung von reaktiven Technologien, zustandslose Controller
• Leistungsstarkes Template-Framework
• kompromisslose Leistung
• einfache Übernahme und Konfiguration
• Unterstützung mehrerer Konfigurationen sowohl für die Entwicklung als auch für den Einsatz in der Produktionsumgebung.

Aber wir möchten auch einige Nachteile erwähnen:

• Langer Projektkompilierungsprozess aufgrund der eher langsamen SBT
• Schlechte Unterstützung von Windows als gleichwertige Entwicklungsplattform

Die Erfahrung mit dem Play Framework hat gezeigt, dass es eines der vielversprechendsten und effizientesten universellen Frameworks ist. Die Java/Scala-Entwickler der Firma Redwerk empfehlen die Verwendung einer Kombination aus Scala + Play + Slick + Akka für neue Projekte wie Rest-API-Services oder Portale mit hoher Last.

ASP.NET Web API

Lassen Sie uns versuchen, einen alternativen Weg für die Entwicklung von Webdiensten auf der Grundlage von .NET für Windows zu finden. Wenn wir früher einen RESTful-Webdienst mit MS .NET-Tools entwickeln wollten, konnten wir entweder ASMX-Webdienste wählen oder REST mit Hilfe von WCF-Technologien implementieren. Aber jetzt, nach der Veröffentlichung einer neuen Version der .NET-Plattform, 4.5, hat ein Entwickler ein neues Tool für die Entwicklung von RESTful-Diensten – ASP.NET Web API. Es handelt sich um ein Framework für WEB, das auf HTTP aufbaut und die Entwicklung von REST-Diensten unter Verwendung gemeinsamer Konventionen und ähnlicher Softwarekonzepte auf schnelle und bequeme Weise ermöglicht. Das Wesen eines neuen Frameworks ist innovativ für die .NET-Plattform im Allgemeinen, aber es wurde zuvor in zahlreichen Web-Frameworks wie Django, Lift, Play Framework, Ruby on Rails, Spring Framework, etc. implementiert. Wir möchten auch darauf hinweisen, dass es sich bei Web API nicht um ein universelles strukturelles Framework wie die oben genannten handelt. Es ist speziell für REST angepasst. Deshalb werden wir im nächsten Teil versuchen, es mit dem Play Framework zu vergleichen.

Werfen wir einen genaueren Blick auf die technische Seite, um die wichtigsten Verbesserungen zu sehen. Da das Framework recht klein ist, werden wir Ihnen zum besseren Verständnis Codebeispiele geben.

Die allgemeine Struktur eines .NET-Web-API-Projekts

Ein Projekt, das auf der .NET Web API-Vorlage basiert, kann über das Menü von Microsoft Visual Studio entwickelt werden, indem es zu einer bestehenden Lösung hinzugefügt wird. Als Ergebnis erhalten wir ein MVC-Projekt mit einer Standardstruktur. Standardmäßig werden zwei Controller erstellt. Sie unterscheiden sich von regulären Controllern, da sie die grundlegende ApiController-Klasse verwenden, die nicht mit einer regulären grundlegenden Controller-Klasse verbunden ist. Controller können die REST-Stilistik mit der Unterstützung von GET, POST, PUT, DELETE-Methoden nutzen. Es gibt keine Standardmethoden von Controllern, die ActionResult zurückgeben. Hier ist ein Beispiel für einen automatisch generierten Code:

public class NumbersController: ApiController {
      // GET api/numbers
      public IEnumerable < string > Get() {
          return new string[] {
              "number1",
              "number2"
          };
      }

      // GET api/numbers/5
      public string Get(int id) {
          return "number";
      }
      // POST api/numbers
      public void Post([FromBody] string newNumber) {}
  }

Routing in der Web-API

Da Klassenmethoden auf relevante REST-Anforderungstypen mit Angabe von HTTP-Methode, URL-Format und Inhaltstyp abgebildet werden, ist Routing zusammen mit Controllern kein Standard. Eine Liste und Definitionen von Routen für Web-API-Controller finden Sie in der Datei WebApiConfig.cs im Ordner App_Start.

Werfen wir einen Blick auf ein Beispiel einer solchen Datei:

public static class WebApiConfig {
      public static void Register(HttpConfiguration config) {
          config.Routes.MapHttpRoute(
          name: "MyNewWebApi",
          routeTemplate: "api/{controller}/{id}",
          defaults: new {
              id = RouteParameter.Optional
          });
      }
  }

Wie Sie aus der obigen Liste ersehen können, haben wir eine Route definiert. Der erste Parameter ist der Name der Route, der zweite ist die Controller-Zuordnung, der dritte ist eine bestimmte Objekt-ID (der dritte Parameter ist in diesem Fall optional).

Zusätzliche Web-API-Funktion

Um alle Möglichkeiten des Frameworks zu demonstrieren, schauen wir uns ein Beispiel für einen komplizierteren Controller an:

public class BooksController: ApiController {
      [Queryable] public IQueryable < Book > Get() {
          return
          new EnumerableQuery < Book > (
          new Collection < Book > {
              new Book {
                  Id = 1, Title = "Tittle1"
              },
              new Book {
                  Id = 2, Title = "Tittle2"
              },
              new Book {
                  Id = 3, Title = "Tittle3"
              },
              new Book {
                  Id = 4, Title = "Tittle4"
              },
              new Book {
                  Id = 5, Title = "Tittle5"
              }
          });
      }
  }

Sie können aus dem obigen Code ersehen, dass wir jetzt eine Sammlung von Instanzen aus dem Controller zurückgeben können. Außerdem sind die Klasse IQueryable und das Attribut der Controller-Methode [Queryable] Teil einer neuen OData-Bibliothek. Die Anwendung dieser Bibliothek ermöglicht es uns, Anfragen mit einem Typsammlungsfilter zu erstellen.

  http://localhost/api/books/?$skip=25
  http://localhost/api/books/?$skip=25&$top=10
  http://localhost/api/books/?$filter=(Id gt 20) and (Id lt 50)&$orderby=Id desc

Ich glaube, es ist nicht nötig zu erklären, was die erste Anforderung bewirkt.
Doch leider gibt es, wie so oft bei Microsoft, abgesehen von zahlreichen Syntax-Goodies und großartigen Innovationen, einen kleinen Makel. Im Moment enthält die OData-Bibliothek keinen Count-Parameter in der Antwort, daher ist es problematisch, eine voll funktionsfähige Paginierung auf Basis der Benutzeroberfläche zu erstellen. Die Entwickler müssen mehrere Bibliotheksklassen entsprechend ihren Anforderungen anpassen. Wie man das macht, finden Sie hier.

Schlussfolgerung

Das .NET Web API Framework ist ein hervorragendes Werkzeug für .NET-Entwickler. Dieses Framework ermöglicht es ihnen, flexiblere Dienste und eine viel einfachere Anwendungsarchitektur zu erstellen und gleichzeitig alle Vorteile der .NET-Plattform im Code zu nutzen. Es vereinfacht auch die Entwicklung und das Testen von REST-Anwendungen im Allgemeinen.

Vergleicht man die Möglichkeiten von Play Framework und .NET Web API, so stellt man fest, dass das erste Framework leistungsfähiger ist und alle führenden Technologien der asynchronen Anfrageverarbeitung implementiert. Play Framework ist ein strukturelles Framework und enthält daher verschiedene Funktionen für alle Zwecke. Das .NET Web API-Framework wiederum ist speziell auf die REST-Struktur ausgerichtet, ermöglicht aber auch die Nutzung aller Funktionen der .NET-Plattform.

Was die Effizienz betrifft, so ist das Play Framework mit Netty Server den meisten Frameworks, einschließlich .NET Web API, um mehrere Schritte voraus. Neben anderen Vorteilen von .NET Web API möchten wir auf die umfangreichen Möglichkeiten der OData-Bibliothek OOB hinweisen – Anforderungsparameter, die die Datenfilterung und die Navigation bei der Datensammlung gewährleisten.

Es liegt an Ihnen zu entscheiden, welche Technologie Sie verwenden möchten. Die Mitarbeiter von Redwerk haben jahrzehntelange Erfahrung in der Entwicklung und Wartung von Projekten sowohl für .NET- als auch für J2EE-Plattformen. Egal, für welche Technologie Sie sich entscheiden, unsere Spezialisten garantieren Ihnen höchste Qualität innerhalb eines angemessenen Zeitrahmens.

Über Redwerk

Redwerk ist ein IT-Outsourcing-Unternehmen, das seit mehr als 13 Jahren hochwertige Softwareprodukte auf der ganzen Welt anbietet. Unsere Büros sind voll von Outsourcing-Softwareentwicklern, die sehr erfahren in der Arbeit mit verschiedenen Mobil-, Web-, Desktop- und Cloud-Technologien sind, mit Scala-Softwareentwicklung als eine unserer Hauptrichtungen. Und unsere ASP.NET-Entwicklungsexperten implementieren Client-Server-Lösungen jeglicher Komplexität. Wenden Sie sich an uns, wenn Sie sich nicht entscheiden können, welche Technologie Sie für Ihr Projekt verwenden möchten. Wir helfen Ihnen dabei, ein maßgeschneidertes Produkt zu erstellen, das alle Ihre Anforderungen erfüllt.