window.pipedriveLeadboosterConfig = { bas: 'leadbooster-chat.pipedrive.com', företagId: 11580370, playbookUuid: '22236db1-6d50-40c4-b48f-8b11262155be', version: 2, } ;(funktion () { var w = fönster if (w.LeadBooster) { console.warn('LeadBooster finns redan') } annars { w.LeadBooster = { q: [], on: funktion (n, h) { this.q.push({ t: "o", n: n, h: h }) }, trigger: funktion (n) { this.q.push({ t: 't', n: n }) }, } } })() Tillämpning av användningsfallsmönstret med Rails - The Codest
Codest
  • Om oss
  • Tjänster
    • Utveckling av programvara
      • Frontend-utveckling
      • Backend-utveckling
    • Staff Augmentation
      • Frontend-utvecklare
      • Backend-utvecklare
      • Dataingenjörer
      • Ingenjörer inom molntjänster
      • QA-ingenjörer
      • Övriga
    • Det rådgivande
      • Revision och rådgivning
  • Industrier
    • Fintech & bankverksamhet
    • E-commerce
    • Adtech
    • Hälsoteknik
    • Tillverkning
    • Logistik
    • Fordon
    • IOT
  • Värde för
    • VD OCH KONCERNCHEF
    • CTO
    • Leveranschef
  • Vårt team
  • Fallstudier
  • Vet hur
    • Blogg
    • Möten
    • Webbinarier
    • Resurser
Karriär Ta kontakt med oss
  • Om oss
  • Tjänster
    • Utveckling av programvara
      • Frontend-utveckling
      • Backend-utveckling
    • Staff Augmentation
      • Frontend-utvecklare
      • Backend-utvecklare
      • Dataingenjörer
      • Ingenjörer inom molntjänster
      • QA-ingenjörer
      • Övriga
    • Det rådgivande
      • Revision och rådgivning
  • Värde för
    • VD OCH KONCERNCHEF
    • CTO
    • Leveranschef
  • Vårt team
  • Fallstudier
  • Vet hur
    • Blogg
    • Möten
    • Webbinarier
    • Resurser
Karriär Ta kontakt med oss
Pil tillbaka GÅ TILLBAKA
2022-04-05
Utveckling av programvara

Tillämpning av användningsfallsmönstret med Rails

Nicolas Nisoria

Ett vanligt problem när man arbetar med Rails är att bestämma var logiken från våra funktioner ska placeras.

Logiken är ofta placerad i Controllers, Models eller om vi har tur i ett Service Object. Så om vi har Service Objects, varför behöver vi då Use Cases?

Följ med mig i den här artikeln för att upptäcka fördelarna med detta mönster.

Användningsfall

Definition

Ett användningsfall är en lista över åtgärder eller händelsesteg som typiskt definierar interaktionen mellan en roll och ett system för att uppnå ett mål.

Det är värt att nämna att detta mönster tillämpas på många olika sätt och har alternativa namn. Vi kan hitta det som Interaktörer, Operatörer eller Kommandonmen i den Ruby samhälle vi håller oss till Användningsfall. Alla implementeringar är olika, men har samma syfte: att tillgodose användarens behov av systemet.

Även om vi i vår projekt Vi definierar inte kraven med hjälp av Användningsfalls och UML är detta mönster fortfarande användbart för att strukturera affärslogiken på ett praktiskt sätt.

Regler

Vår Användningsfall måste vara det:

  • Agnostiskt ramverk
  • Agnostisk databas
  • Ansvarar bara för en sak (definierar stegen för att uppnå användarens mål)

Fördelar

  • Läsbarhet: Lätt att läsa och förstå eftersom stegen är tydligt definierade.
  • Frikoppling: Flytta logiken från Controllers och Models och skapa en ny abstraktionsnivå.
  • Synlighet: Kodbasen avslöjar vilka funktioner som finns i systemet.

I praktiken

Låt oss ta ett exempel med en användare som vill köpa något i vårt system.

modul Användningsfall
  modul Köpare
    klass Köp
      def initialize(köpare:, kundvagn:)
        @köpare = köpare
        @vagn = vagn
      slut
      def anrop
        retur om inte check_stock
        retur om inte create_purchase
meddela slut
privat
      attr_läsare :köpare, :kundvagn
      def check_stock
        Tjänster::CheckStock.call(kundvagn: kundvagn)
slut
      def create_purchase
        Services::CreatePurchase.call(köpare: köpare, kundvagn: kundvagn).call
      end
      def notifiera

         Services::NotifyBuyer.call(köpare: köpare)
       end
     slut
   slut
 slut

Som du kan se i detta kod exempel skapade vi en ny Användningsfall som heter Purchase. Vi definierade bara en offentlig metod samtal. Inuti anropsmetoden hittar vi ganska grundläggande steg för att göra ett köp, och alla steg är definierade som privata metoder. Varje steg anropar ett serviceobjekt, på så sätt kan vår Användningsfall definierar bara stegen för att genomföra ett köp och inte själva logiken. Detta ger oss en tydlig bild av vad som kan göras i vårt system (göra ett köp) och stegen för att uppnå detta.

Nu är vi redo att anropa vår första Användningsfall från en controller.

klass Controller
  def köp
    UseCases::Köpare::Köp.new(
      köpare: purchase_params[:buyer],
      cart: köp_parametrar[:cart]
    ).call

    ...
  slut

  ...
slut

Ur detta perspektiv är Användningsfall ser ungefär ut som ett Service Object men syftet är annorlunda. Ett serviceobjekt utför en uppgift på låg nivå och interagerar med olika delar av systemet, t.ex. databasen, medan Användningsfall skapar en ny abstraktion på hög nivå och definierar de logiska stegen.

Förbättringar

Vår första Användningsfall fungerar men kan bli bättre. Hur kan vi förbättra det? Låt oss använda oss av torr ädelstenar. I det här fallet kommer vi att använda torr-transaktion.

Låt oss först definiera vår basklass.

klass UseCase
  include Dry::Transaktion

  klass << själv
    def anrop(**args)
      ny.anrop(**args)
    slut
  slut
slut

Detta kommer att hjälpa oss att skicka attribut till UseCase-transaktionen och använda dem. Sedan är vi redo att omdefiniera vårt Purchase Use Case.

modul Användningsfall
  modul Köpare
    klass Köp
      def initialize(köpare:, kundvagn:)
        @köpare = köpare
        @vagn = vagn
      slut

      def anrop
        retur om inte check_stock
        retur om inte create_purchase
        meddela
      avsluta

      privat

      attr_reader :köpare, :kundvagn

      def check_stock
        Tjänster::CheckStock.call(kundvagn: kundvagn)
      slut

      def create_purchase
        Services::CreatePurchase.call(köpare: köpare, kundvagn: kundvagn).call
      slut

      def notify
        Services::NotifyBuyer.call(köpare: köpare)
      end
    slut
   slut
 slut

Med de nya ändringarna kan vi på ett tydligt sätt se hur våra steg definieras och vi kan hantera resultatet av varje steg med Success() och Failure().

Vi är redo att anropa vårt nya Use Case i styrenheten och förbereda vårt svar beroende på slutresultatet.

klass Controller
  def köp
    UseCases::Köpare::Köp.new.call(
      köpare: purchase_params[:buyer],
      cart: köp_parametrar[:cart]
    ) do |resultat|
      resultat.framgång do
        ...
      slut
      result.failure do
        ...
      slut
    slut

    ...
  slut

  ...
slut

Det här exemplet skulle kunna förbättras ännu mer med valideringar, men det räcker för att visa hur kraftfullt det här mönstret är.

Slutsatser

Låt oss vara ärliga här, den Mönster för användningsfall är ganska enkel och ser ut ungefär som ett Service Object, men den här abstraktionsnivån kan innebära stora förändringar i din applikation.

Tänk dig att en ny utvecklare ansluter sig till projektet och öppnar mappen use_cases, som ett första intryck kommer han att ha en lista över alla funktioner som finns i systemet och efter att ha öppnat ett användningsfall kommer han att se alla nödvändiga steg för den funktionen utan att gå djupt in i logiken. Denna känsla av ordning och kontroll är den största fördelen med det här mönstret.

Ta med detta i din verktygslåda och kanske kommer du att ha nytta av det i framtiden.

Relaterade artiklar

Utveckling av programvara

Ruby on Rails Modularisering med Packwerk Avsnitt I

Människor har svårt att se helheten i ett problem utan att ägna mycket tid och kraft åt det. Detta händer särskilt när man arbetar med stora och komplexa applikationer. ....

Nicolas Nisoria
Utveckling av programvara

Ruby on Rails-modularisering med Packwerk Episode II

I det andra avsnittet av vår Ruby on Rails-modularisering med Packwerk kommer vi att titta närmare på konceptet med applikation som ett paket.

Nicolas Nisoria
Utveckling av programvara

Räls och andra transportmedel

Rails är ett Rack-kompatibelt ramverk med fokus på snabb applikationsutveckling. Tyvärr leder "allt ur lådan"-strategin och det blinda Rails-beteendet ofta till att applikationskoden förlorar kvalitet, ...

Codest
Krzysztof Buszewicz Senior Software Engineer

Prenumerera på vår kunskapsbas och håll dig uppdaterad om expertisen från IT-sektorn.

    Om oss

    The Codest - Internationellt mjukvaruutvecklingsföretag med teknikhubbar i Polen.

    Förenade kungariket - Huvudkontor

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

    Polen - Lokala tekniknav

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

      Codest

    • Hem
    • Om oss
    • Tjänster
    • Fallstudier
    • Vet hur
    • Karriär
    • Ordbok

      Tjänster

    • Det rådgivande
    • Utveckling av programvara
    • Backend-utveckling
    • Frontend-utveckling
    • Staff Augmentation
    • Backend-utvecklare
    • Ingenjörer inom molntjänster
    • Dataingenjörer
    • Övriga
    • QA-ingenjörer

      Resurser

    • Fakta och myter om att samarbeta med en extern partner för mjukvaruutveckling
    • Från USA till Europa: Varför väljer amerikanska startup-företag att flytta till Europa?
    • Jämförelse av Tech Offshore Development Hubs: Tech Offshore Europa (Polen), ASEAN (Filippinerna), Eurasien (Turkiet)
    • Vilka är de största utmaningarna för CTO:er och CIO:er?
    • Codest
    • Codest
    • Codest
    • Privacy policy
    • Användarvillkor för webbplatsen

    Copyright © 2025 av The Codest. Alla rättigheter reserverade.

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