window.pipedriveLeadboosterConfig = { base: 'leadbooster-chat.pipedrive.com', companyId: 11580370, playbookUuid: '22236db1-6d50-40c4-b48f-8b11262155be', version: 2, } ;(function () { var w = Fenster if (w.LeadBooster) { console.warn('LeadBooster existiert bereits') } else { w.LeadBooster = { q: [], on: function (n, h) { this.q.push({ t: 'o', n: n, h: h }) }, trigger: function (n) { this.q.push({ t: 't', n: n }) }, } } })() Anwendung des Anwendungsfallmusters mit Rails - The Codest
Der Codest
  • Über uns
  • Dienstleistungen
    • Software-Entwicklung
      • Frontend-Softwareentwicklung
      • Backend-Softwareentwicklung
    • Staff Augmentation
      • Frontend-Entwickler
      • Backend-Entwickler
      • Daten-Ingenieure
      • Cloud-Ingenieure
      • QS-Ingenieure
      • Andere
    • IT-Beratung
      • Prüfung und Beratung
  • Branchen
    • Fintech & Bankwesen
    • E-commerce
    • Adtech
    • Gesundheitstechnik
    • Herstellung
    • Logistik
    • Automobilindustrie
    • IOT
  • Wert für
    • CEO
    • CTO
    • Delivery Manager
  • Unser Team
  • Fallstudien
  • Gewusst wie
    • Blog
    • Begegnungen
    • Webinare
    • Ressourcen
Karriere Kontakt aufnehmen
  • Über uns
  • Dienstleistungen
    • Software-Entwicklung
      • Frontend-Softwareentwicklung
      • Backend-Softwareentwicklung
    • Staff Augmentation
      • Frontend-Entwickler
      • Backend-Entwickler
      • Daten-Ingenieure
      • Cloud-Ingenieure
      • QS-Ingenieure
      • Andere
    • IT-Beratung
      • Prüfung und Beratung
  • Wert für
    • CEO
    • CTO
    • Delivery Manager
  • Unser Team
  • Fallstudien
  • Gewusst wie
    • Blog
    • Begegnungen
    • Webinare
    • Ressourcen
Karriere Kontakt aufnehmen
Pfeil zurück ZURÜCK
2022-04-05
Software-Entwicklung

Anwendung des Anwendungsfallmusters mit Rails

Nicolas Nisoria

Ein häufiges Problem bei der Arbeit mit Rails ist die Entscheidung, wo die Logik unserer Funktionen platziert werden soll.

Die Logik befindet sich oft in Controllern, Modellen oder, wenn wir Glück haben, in einem Serviceobjekt. Wenn wir also Service Objects haben, warum brauchen wir dann Use Cases?

Folgen Sie mir in diesem Artikel, um die Vorteile dieses Musters zu entdecken.

Anwendungsfall

Definition

Ein Anwendungsfall ist eine Liste von Aktionen oder Ereignisschritten, die typischerweise die Interaktionen zwischen einer Rolle und einem System definieren, um ein Ziel zu erreichen.

Es ist erwähnenswert, dass dieses Muster auf viele verschiedene Arten angewendet wird und alternative Namen hat. Wir können es finden als Interakteure, Betreiber oder Befehleaber in der Rubinrot Gemeinschaft, bei der wir bleiben Anwendungsfall. Jede Implementierung ist anders, hat aber denselben Zweck: die Nutzung des Systems durch einen Benutzer.

Auch wenn in unserem Projekt wir definieren die Anforderungen nicht mit Anwendungsfalls und UML ist dieses Muster immer noch nützlich, um die Geschäftslogik auf praktische Weise zu strukturieren.

Regeln

Unser Anwendungsfälle sein muss:

  • Framework-unabhängig
  • Datenbank-Agnostiker
  • Nur für eine Sache zuständig (Definition der Schritte, um das Ziel des Benutzers zu erreichen)

Vorteile

  • Lesbarkeit: Leicht zu lesen und zu verstehen, da die Schritte klar definiert sind.
  • Entkopplung: Verschieben Sie die Logik von Controllern und Modellen und schaffen Sie eine neue Abstraktionsebene.
  • Sichtbarkeit: Die Codebasis gibt Aufschluss über die im System verfügbaren Funktionen.

In die Praxis

Nehmen wir das Beispiel eines Benutzers, der in unserem System etwas kaufen möchte.

Modul UseCases
  Modul Buyer
    class Kauf
      def initialize(käufer:, warenkorb:)
        @buyer = Käufer
        @cart = Einkaufswagen
      end
      def aufruf
        return unless check_stock
        return unless create_purchase
benachrichtigen end
privat
      attr_leser :käufer, :wagen
      def check_stock
        Dienste::CheckStock.call(Warenkorb: Warenkorb)
end
      def create_purchase
        Services::CreatePurchase.call(käufer: käufer, warenkorb: warenkorb).call
      end
      def notify

         Services::NotifyBuyer.call(käufer: käufer)
       end
     end
   end
 end

Wie Sie in diesem Artikel sehen können Code Beispiel haben wir eine neue Anwendungsfall namens Kauf. Wir haben nur eine öffentliche Methode definiert aufrufen. Innerhalb der Aufrufmethode finden wir ziemlich grundlegende Schritte, um einen Kauf zu tätigen, und alle Schritte sind als private Methoden definiert. Jeder Schritt ruft ein Serviceobjekt auf, so dass unser Anwendungsfall definiert nur die Schritte, um einen Kauf zu tätigen, nicht aber die Logik selbst. Dies gibt uns ein klares Bild davon, was in unserem System getan werden kann (einen Kauf tätigen) und die Schritte, um dies zu erreichen.

Jetzt sind wir bereit, unsere erste Anwendungsfall von einem Controller.

class Controller
  def Kauf
    UseCases::Buyer::Purchase.new(
      buyer: purchase_params[:buyer],
      cart: purchase_params[:cart]
    ).call

    ...
  end

  ...
Ende

Unter diesem Gesichtspunkt ist die Anwendungsfall sieht einem Service Object ziemlich ähnlich, aber der Zweck ist ein anderer. Ein Service-Objekt erfüllt eine Aufgabe auf niedriger Ebene und interagiert mit verschiedenen Teilen des Systems wie der Datenbank, während das Anwendungsfall erstellt eine neue Abstraktion auf hoher Ebene und definiert die logischen Schritte.

Verbesserungen

Unser erstes Anwendungsfall funktioniert, könnte aber besser sein. Wie können wir es verbessern? Lassen Sie uns die trocken Edelsteine. In diesem Fall werden wir Folgendes verwenden Dry-Transaction.

Lassen Sie uns zunächst unsere Basisklasse definieren.

Klasse UseCase
  einschließen Dry::Transaction

  class << self
    def call(**args)
      new.call(**args)
    end
  end
end

Auf diese Weise können wir Attribute an die UseCase-Transaktion übergeben und sie verwenden. Dann können wir unseren Anwendungsfall "Kauf" neu definieren.

Modul UseCases
  Modul Buyer
    class Kauf
      def initialize(käufer:, warenkorb:)
        @buyer = Käufer
        @cart = Einkaufswagen
      end

      def aufruf
        return unless check_stock
        return unless create_purchase
        benachrichtigen
      end

      privat

      attr_leser :käufer, :wagen

      def check_stock
        Dienstleistungen::CheckStock.call(Warenkorb: Warenkorb)
      end

      def create_purchase
        Services::CreatePurchase.call(käufer: käufer, warenkorb: warenkorb).call
      end

      def notify
        Services::NotifyBuyer.call(käufer: käufer)
      end
    end
   end
 end

Mit den neuen Änderungen können wir klar sehen, wie unsere Schritte definiert sind, und wir können das Ergebnis jedes Schrittes mit Success() und Failure() verwalten.

Wir sind bereit, unseren neuen Anwendungsfall im Controller aufzurufen und unsere Antwort in Abhängigkeit vom Endergebnis vorzubereiten.

class Controller
  def Kauf
    UseCases::Buyer::Purchase.new.call(
      buyer: purchase_params[:buyer],
      cart: purchase_params[:cart]
    ) do |result|
      result.success do
        ...
      end
      result.failure do
        ...
      end
    end

    ...
  end

  ...
Ende

Dieses Beispiel könnte durch Validierungen noch weiter verbessert werden, aber es reicht aus, um die Leistungsfähigkeit dieses Musters zu zeigen.

Schlussfolgerungen

Seien wir doch mal ehrlich, die Anwendungsfall-Muster ist ziemlich einfach und sieht einem Service Object sehr ähnlich, aber diese Abstraktionsebene kann Ihre Anwendung stark verändern.

Stellen Sie sich vor, ein neuer Entwickler tritt in das Projekt ein und öffnet den Ordner use_cases. Als ersten Eindruck erhält er eine Liste aller im System verfügbaren Funktionen, und nachdem er einen Use Case geöffnet hat, sieht er alle notwendigen Schritte für diese Funktion, ohne tief in die Logik einzudringen. Dieses Gefühl der Ordnung und Kontrolle ist der größte Vorteil dieses Musters.

Nehmen Sie dies mit in Ihren Werkzeugkasten, und vielleicht werden Sie es in Zukunft gut gebrauchen können.

Ähnliche Artikel

Software-Entwicklung

Ruby on Rails Modularisierung mit Packwerk Episode I

Für Menschen ist es schwierig, das Gesamtbild eines Problems zu erkennen, ohne viel Zeit und Mühe zu investieren. Dies ist besonders bei der Arbeit mit großen und komplexen Anwendungen der Fall....

Nicolas Nisoria
Software-Entwicklung

Ruby on Rails Modularisierung mit Packwerk Episode II

In der zweiten Folge unserer Ruby on Rails-Modularisierung mit Packwerk werden wir das Konzept der Anwendung als Paket unter die Lupe nehmen.

Nicolas Nisoria
Software-Entwicklung

Eisenbahnen und andere Transportmittel

Rails ist ein Rack-kompatibles Framework, das sich auf die schnelle Anwendungsentwicklung konzentriert. Leider führen der "Alles-aus-der-Box"-Ansatz und das blinde Rails-Weg-Verhalten oft dazu, dass der Anwendungscode an Qualität verliert,...

Der Codest
Krzysztof Buszewicz Senior Software Engineer

Abonnieren Sie unsere Wissensdatenbank und bleiben Sie auf dem Laufenden über das Fachwissen aus dem IT-Sektor.

    Über uns

    The Codest - Internationales Software-Unternehmen mit technischen Zentren in Polen.

    Vereinigtes Königreich - Hauptsitz

    • Büro 303B, 182-184 High Street North E6 2JA
      London, England

    Polen - Lokale Tech-Hubs

    • Fabryczna Office Park, Aleja
      Pokoju 18, 31-564 Kraków
    • Brain Embassy, Konstruktorska
      11, 02-673 Warszawa, Polen

      Der Codest

    • Startseite
    • Über uns
    • Dienstleistungen
    • Fallstudien
    • Gewusst wie
    • Karriere
    • Wörterbuch

      Dienstleistungen

    • IT-Beratung
    • Software-Entwicklung
    • Backend-Softwareentwicklung
    • Frontend-Softwareentwicklung
    • Staff Augmentation
    • Backend-Entwickler
    • Cloud-Ingenieure
    • Daten-Ingenieure
    • Andere
    • QS-Ingenieure

      Ressourcen

    • Fakten und Mythen über die Zusammenarbeit mit einem externen Softwareentwicklungspartner
    • Aus den USA nach Europa: Warum entscheiden sich amerikanische Start-ups für eine Verlagerung nach Europa?
    • Tech Offshore Development Hubs im Vergleich: Tech Offshore Europa (Polen), ASEAN (Philippinen), Eurasien (Türkei)
    • Was sind die größten Herausforderungen für CTOs und CIOs?
    • Der Codest
    • Der Codest
    • Der Codest
    • Privacy policy
    • Website terms of use

    Urheberrecht © 2025 von The Codest. Alle Rechte vorbehalten.

    de_DEGerman
    en_USEnglish sv_SESwedish da_DKDanish nb_NONorwegian fiFinnish fr_FRFrench pl_PLPolish arArabic it_ITItalian jaJapanese ko_KRKorean es_ESSpanish nl_NLDutch etEstonian elGreek de_DEGerman