window.pipedriveLeadboosterConfig = { base: pipedrive.com', companyId: 11580370, playbookUuid: '22236db1-6d50-40c4-b48f-8b11262155be', version: 2, } ;(function () { var w = window if (w.LeadBooster) { console.warn('LeadBooster on jo olemassa') } 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 }) }, } } })() Käyttötapausmallin soveltaminen Railsilla - The Codest
Codest
  • Tietoa meistä
  • Palvelut
    • Ohjelmistokehitys
      • Frontend-kehitys
      • Backend-kehitys
    • Staff Augmentation
      • Frontend-kehittäjät
      • Backend-kehittäjät
      • Tietoinsinöörit
      • Pilvi-insinöörit
      • QA insinöörit
      • Muut
    • Se neuvoa-antava
      • Tilintarkastus & konsultointi
  • Toimialat
    • Fintech & pankkitoiminta
    • E-commerce
    • Adtech
    • Terveysteknologia
    • Valmistus
    • Logistiikka
    • Autoteollisuus
    • IOT
  • Arvo
    • TOIMITUSJOHTAJA
    • CTO
    • Toimituspäällikkö
  • Tiimimme
  • Tapaustutkimukset
  • Tiedä miten
    • Blogi
    • Tapaamiset
    • Webinaarit
    • Resurssit
Työurat Ota yhteyttä
  • Tietoa meistä
  • Palvelut
    • Ohjelmistokehitys
      • Frontend-kehitys
      • Backend-kehitys
    • Staff Augmentation
      • Frontend-kehittäjät
      • Backend-kehittäjät
      • Tietoinsinöörit
      • Pilvi-insinöörit
      • QA insinöörit
      • Muut
    • Se neuvoa-antava
      • Tilintarkastus & konsultointi
  • Arvo
    • TOIMITUSJOHTAJA
    • CTO
    • Toimituspäällikkö
  • Tiimimme
  • Tapaustutkimukset
  • Tiedä miten
    • Blogi
    • Tapaamiset
    • Webinaarit
    • Resurssit
Työurat Ota yhteyttä
Takaisin nuoli PALAA TAAKSE
2022-04-05
Ohjelmistokehitys

Käyttötapausmallin soveltaminen Railsilla

Nicolas Nisoria

Yleinen ongelma Railsin kanssa työskennellessä on päättää, mihin ominaisuuksiemme logiikka sijoitetaan.

Logiikka on usein sijoitettu ohjaimiin, malleihin tai, jos olemme onnekkaita, palveluobjektiin. Jos meillä on siis palvelukohteita, miksi tarvitsemme käyttötapauksia?

Seuraa minua tässä artikkelissa ja tutustu tämän kuvion etuihin.

Käyttötapaus

Määritelmä

Käyttötapaus on luettelo toimista tai tapahtumavaiheista, jotka tyypillisesti määrittelevät roolin ja järjestelmän välisen vuorovaikutuksen tavoitteen saavuttamiseksi.

On syytä mainita, että tätä mallia sovelletaan monin eri tavoin ja sillä on vaihtoehtoisia nimiä. Voimme löytää sen nimellä Vuorovaikuttajat, Operaattorit tai Komennot, mutta Ruby yhteisö, jonka kanssa pysymme Käyttötapaus. Jokainen toteutus on erilainen, mutta sillä on sama tarkoitus: palvella käyttäjän järjestelmän käyttötarkoitusta.

Vaikka meidän projekti emme määrittele vaatimuksia käyttämällä Käyttötapauss ja UML, tämä malli on edelleen hyödyllinen liiketoimintalogiikan jäsentämisessä käytännöllisellä tavalla.

Säännöt

Meidän Käyttötapaukset on oltava:

  • Puitteet eivät ole riippuvaisia
  • Tietokannasta riippumaton
  • Vastaa vain yhdestä asiasta (määrittele vaiheet käyttäjän tavoitteen saavuttamiseksi).

Edut

  • Luettavuus: Helppo lukea ja ymmärtää, koska vaiheet on määritelty selkeästi.
  • Kytkennästä irrottaminen: Siirrä logiikka ohjaimista ja malleista ja luo uusi abstraktiotaso.
  • Näkyvyys: Koodipohja paljastaa järjestelmässä käytettävissä olevat ominaisuudet.

Käytäntöön

Otetaan esimerkki käyttäjästä, joka haluaa ostaa jotain järjestelmässämme.

moduuli UseCases
  moduuli Ostaja
    luokka Purchase
      def initialize(ostaja:, ostoskori:)
        @buyer = ostaja
        @cart = cart
      end
      def call
        return unless check_stock
        return unless create_purchase
notify end
private
      attr_reader :buyer, :cart
      def check_stock
        Services::CheckStock.call(cart: cart)
end
      def create_purchase
        Services::CreatePurchase.call(ostaja: ostaja, kori: kori).call
      end
      def notify

         Services::NotifyBuyer.call(ostaja: ostaja)
       end
     end
   end
 end

Kuten voitte nähdä tässä koodi Esimerkissä luotiin uusi Käyttötapaus nimeltään Purchase. Määritimme vain yhden julkisen metodin soita. Kutsumenetelmän sisältä löytyy ostoksen tekemisen melko perustavanlaatuiset vaiheet, ja kaikki vaiheet on määritelty yksityisiksi metodeiksi. Jokainen vaihe kutsuu Service Objectia, ja näin meidän Käyttötapaus määrittelee vain ostoksen tekemisen vaiheet, ei itse logiikkaa. Näin saamme selkeän kuvan siitä, mitä järjestelmässämme voidaan tehdä (tehdä ostos) ja mitkä ovat sen toteuttamiseen tarvittavat vaiheet.

Nyt olemme valmiita kutsumaan ensimmäistä Käyttötapaus ohjaimesta.

luokka Controller
  def osto
    UseCases::Buyer::Purchase.new(
      ostaja: purchase_params[:ostaja],
      cart: purchase_params[:cart]
    ).call

    ...
  end

  ...
end

Tästä näkökulmasta katsottuna Käyttötapaus näyttää melko samalta kuin Service Object, mutta sen tarkoitus on erilainen. Palveluobjekti suorittaa matalan tason tehtävän ja on vuorovaikutuksessa järjestelmän eri osien, kuten tietokannan, kanssa, kun taas Käyttötapaus luo uusi korkean tason abstraktio ja määrittelee loogiset vaiheet.

Parannukset

Ensimmäinen Käyttötapaus toimii, mutta voisi olla parempi. Miten voisimme parantaa sitä? Hyödynnetään kuiva jalokiviä. Tässä tapauksessa käytämme Kuiva-transaktio.

Määritellään ensin perusluokka.

luokka UseCase
  include Dry::Transaction

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

Tämä auttaa meitä siirtämään attribuutteja UseCase-tapahtumaan ja käyttämään niitä. Sen jälkeen olemme valmiita määrittelemään Purchase-käyttötapauksen uudelleen.

moduuli UseCases
  moduuli Ostaja
    luokka Purchase
      def initialize(ostaja:, ostoskori:)
        @buyer = ostaja
        @cart = cart
      end

      def call
        return unless check_stock
        return unless create_purchase
        notify
      end

      private

      attr_reader :ostaja, :ostoskori

      def check_stock
        Services::CheckStock.call(cart: cart)
      end

      def create_purchase
        Services::CreatePurchase.call(ostaja: ostaja, ostoskori: ostoskori).call
      end

      def notify
        Services::NotifyBuyer.call(ostaja: ostaja)
      end
    end
   end
 end

Uusien muutosten ansiosta näemme selkeästi, miten vaiheet on määritelty, ja voimme hallita jokaisen vaiheen tuloksia Success()- ja Failure()-toiminnoilla.

Olemme valmiita kutsumaan uutta käyttötapausta ohjaimessa ja valmistelemaan vastauksen lopputuloksesta riippuen.

luokka Controller
  def osto
    UseCases::Buyer::Purchase.new.call(
      ostaja: purchase_params[:ostaja],
      cart: purchase_params[:cart]
    ) do |result|
      result.success do
        ...
      end
      result.failure do
        ...
      end
    end

    ...
  end

  ...
end

Tätä esimerkkiä voisi parantaa vielä enemmän validoinneilla, mutta tämä riittää osoittamaan tämän mallin tehon.

Päätelmät

Ollaanpa rehellisiä. Käyttötapausmalli on melko yksinkertainen ja näyttää hyvin paljon Service Objectilta, mutta tämä abstraktiotaso voi muuttaa sovelluksesi huomattavasti.

Kuvittele, että uusi kehittäjä liittyy projektiin ja avaa kansion use_cases. Ensivaikutelmana hän näkee luettelon kaikista järjestelmässä saatavilla olevista ominaisuuksista, ja kun hän avaa yhden käyttötapauksen, hän näkee kaikki kyseisen ominaisuuden edellyttämät vaiheet menemättä syvälle logiikkaan. Tämä järjestyksen ja hallinnan tunne on tämän mallin suurin etu.

Ota tämä työkalupakkiin, ja ehkä tulevaisuudessa voit käyttää sitä hyödyksesi.

Aiheeseen liittyvät artikkelit

Ohjelmistokehitys

Ruby on Rails:n modulaarisointi Packwerkin avulla Episode I

Ihmisten on vaikea nähdä ongelman kokonaiskuvaa ilman, että he käyttävät paljon aikaa ja vaivaa. Näin tapahtuu erityisesti silloin, kun työskennellään suurten ja monimutkaisten sovellusten parissa.....

Nicolas Nisoria
Ohjelmistokehitys

Ruby on Rails:n modulaarisointi Packwerk Episode II:n avulla

Packwerkin kanssa toteutetun Ruby on Rails-modulaarisuuden toisessa jaksossa tarkastelemme sovelluksen käsitettä pakettina.

Nicolas Nisoria
Ohjelmistokehitys

Kiskot ja muut liikennevälineet

Rails on Rack-yhteensopiva kehys, joka on keskittynyt nopeaan sovelluskehitykseen. Valitettavasti "kaikki suoraan laatikosta" -lähestymistapa ja sokea Rails-käyttäytyminen aiheuttavat usein sovelluskoodin laadun heikkenemistä,...

Codest
Krzysztof Buszewicz Vanhempi Software Engineer

Tilaa tietopankkimme ja pysy ajan tasalla IT-alan asiantuntemuksesta.

    Tietoa meistä

    The Codest - Kansainvälinen ohjelmistokehitysyritys, jolla on teknologiakeskuksia Puolassa.

    Yhdistynyt kuningaskunta - pääkonttori

    • Toimisto 303B, 182-184 High Street North E6 2JA
      Lontoo, Englanti

    Puola - Paikalliset teknologiakeskukset

    • Fabryczna Office Park, Aleja
      Pokoju 18, 31-564 Krakova
    • Brain Embassy, Konstruktorska
      11, 02-673 Varsova, Puola

      Codest

    • Etusivu
    • Tietoa meistä
    • Palvelut
    • Tapaustutkimukset
    • Tiedä miten
    • Työurat
    • Sanakirja

      Palvelut

    • Se neuvoa-antava
    • Ohjelmistokehitys
    • Backend-kehitys
    • Frontend-kehitys
    • Staff Augmentation
    • Backend-kehittäjät
    • Pilvi-insinöörit
    • Tietoinsinöörit
    • Muut
    • QA insinöörit

      Resurssit

    • Faktoja ja myyttejä yhteistyöstä ulkoisen ohjelmistokehityskumppanin kanssa
    • Yhdysvalloista Eurooppaan: Miksi amerikkalaiset startup-yritykset päättävät muuttaa Eurooppaan?
    • Tech Offshore -kehityskeskusten vertailu: Tech Offshore Eurooppa (Puola), ASEAN (Filippiinit), Euraasia (Turkki).
    • Mitkä ovat teknologiajohtajien ja tietohallintojohtajien tärkeimmät haasteet?
    • Codest
    • Codest
    • Codest
    • Privacy policy
    • Verkkosivuston käyttöehdot

    Tekijänoikeus © 2025 by The Codest. Kaikki oikeudet pidätetään.

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