Olen luonut yksinkertaisen MVC Java -sovelluksen, joka lisää tietueet tietolomakkeiden kautta tietokantaan.
Sovellukseni kerää tietoja, se myös vahvistaa ja tallentaa ne. Tämä johtuu siitä, että tietoja hankitaan verkossa eri käyttäjiltä. tiedot ovat pääosin numeerisia.
Nyt kun tietokantaan (SQL-palvelimelle) tallennetaan numeerisia tietoja, haluan, että sovellukseni suorittaa laskutoimituksia ja näyttää tulokset. Käyttäjä ei ole kiinnostunut siitä, miten laskelmat tehdään, joten ne on kapseloitava. Käyttäjän on pystyttävä tarkastelemaan vain yksinkertaisia laskettuja tietoja (esimerkiksi A-saraketiedot miinus B Sarake-tiedot jaettuna C-saraketiedoilla). Tiedän kuinka kirjoittaa tallennetut menettelyt samalle, mutta haluan kolmitasoisen sovelluksen.
Haluan, että tietokantaan tallennettuihin tietoihin lisätään laskelmat. Alkuperäisiin tietoihin ei tule vaikuttaa, kun taas uudet tiedot, jälkilaskelmat, on tallennettava uutena kokonaisuustietueena tietokantaan.
Mihin minun pitäisi kirjoittaa koodi tätä taustalaskentaa varten? Koska se on sääntöjä ja liiketoimintalogiikkaa, pitäisikö minun laittaa se uusiin JavaBeans-tiedostoihin?
Kommentit
- mahdollinen kaksoiskappale OO: n pysyminen ja testattavuus tietokannan kanssa työskennellessäsi
- Liiketoimintalogiikka on alias tiimissäsi / osastollasi olevalle kaverille, jolta kysyt, miten tehdä / käyttää mallia. Tämän vuoksi ’ s, liiketoimintalogiikka voidaan tallentaa erilliseen luokkaan nimeltä Business logic. Sama koskee Presentation Logicia, joka on synonyymi suunnittelijalle, joka vastaa kysymyksiisi käyttöliittymäkomponenttien alustamisesta tai näyttämisestä. Siellä voi olla myös kehittäjälogiikka (kysymykset, joihin sinä itse tai kollegasi kysyt ja vastaat) edustaa tietoa siitä, miten ohjelmakomponentit luodaan ja yhdistetään toisiinsa.
Vastaus
-liikelogiikka tulisi sijoittaa malli , ja meidän tulisi pyrkiä rasvaisiin malleihin ja laihoihin ohjaimiin .
Aloituskohteena meidän tulisi aloittaa ohjaimen logiikasta. Esimerkiksi: päivityksessä , ohjaimesi ohjaa koodisi menetelmä / palvelu , joka toimittaa muutokset malliin.
Mallissa voimme helposti luoda auttaja / palvelu luokat, joissa sovelluksen liiketoimintasäännöt tai laskelmat voidaan vahvistaa.
Käsitteellinen yhteenveto
-
Ohjain on tarkoitettu sovelluslogiikalle. Logiikka, joka on erityinen sille, miten sovelluksesi haluaa olla vuorovaikutuksessa ” tietotunnuksen ” kanssa, johon se kuuluu.
-
-malli on logiikkaa varten, joka on riippumaton sovelluksesta . Tämän logiikan tulee olla kelvollinen kaikissa ” -tietotunnuksen ” siihen kuuluvissa sovelluksissa.
-
Siksi on loogista sijoittaa kaikki liiketoimintasäännöt malliin.
Kommentit
- mukava selkeä ja ytimekäs vastaus ..
- @Yusubov, voisitteko selittää minulle eron sovelluslogiikan ja liiketoimintalogiikan välillä
- @Moh, Lyhyesti sanottuna nämä ovat sanoja, jotka auttavat kuvata sovelluksen tekniikan tasoja. Liikelogiikka on periaatteessa järjestelmän sääntöjä toiminnallisten eritelmien mukaisesti. Esimerkiksi tyypin B objektilla A on oltava määritetty C ja D, mutta ei E. Sovelluslogiikka on pikemminkin tekninen eritelmä, kuten Java-palvelinsovellusten ja OJB: n käyttäminen Oracle-tietokantaan pysymiseksi.
- Haluatko tarkenna näitä sanoja:
The most common mistakes are to implement application logic operations inside the controller or the view(presentation) layer.[ php-html.net/tutorials/model-view-controller-in-php] - Jos ymmärsin oikein, mainitussa artikkelissa ’ -sovelluslogiikkaa ’ kutsutaan ’ liiketoimintalogiikka ’. Siksi mitään, joka viittaa liiketoimintalogiikkaan, ei tule sijoittaa ohjaimeen tai näkymään.
Vastaa
Kuten aina, se riippuu projektin monimutkaisuudesta.
Triviaaleissa sovelluksissa, joissa verkkotunnusmallin monimutkaisuus on suhteellisen pieni, voit laittaa logiikan malleihin ja kutsua sitä päiväksi.
Kuitenkin muissa kuin triviaalisissa sovelluksissa, joissa on monimutkaiset mallit ja paljon liiketoimintasääntöjä, on parempi erottaa asiat hieman enemmän.
Jos laitat liiketoimintalogiikan, johon sisältyy useampi kuin yksi malli, mallissa, otat käyttöön tiukan kytkennän näiden mallien välillä.Kun sovellukset kasvavat edelleen, näistä malleista on taipumus muuttua liikaa tietäen god models. Ja tästä tulee nopeasti iso sotku, jota on vaikea testata ja ylläpitää. Joten siinä tapauksessa on hyödyllistä laittaa logiikka erilliseen kerrokseen.
Kun päätät abstraktiosta, ota aina huomioon sovelluksesi monimutkaisuus ja tarkoitukset ja vältä ylisuunnittelua. Triviaaleissa / pienissä sovelluksissa enemmän kerroksia kuin tarvitsee lisäämällä monimutkaisuutta sen sijaan, että vähennettäisiin sitä.
Robert Martinilla (Bob-setä) on hyvä blogiviesti aiheesta: Puhdas arkkitehtuuri.
Kommentit
- kysymys koski MVC: tä. liiketoimintalogiikan tulisi aina olla mallissa. Ohjain on vain sovitin.
- MVC on yksi alan ylikuormitetuimmista termeistä. En halua ’ halua päästä tämän termin mielikuvituksiin, koska se edellyttää kirjaa. MVC: n käyttö ei tarkoita sitä, että sinun on lisättävä kaikki logiikat malleihin.
- Steve Burbeckin (Smalltalk-tiimi) määritelmästä:
The controller interprets the mouse and keyboard inputs from the user, commanding the model and/or the view to change as appropriate. Se ’ on sovittimen määritelmä. - Jos laitat malliin kaiken logiikan, päädyt tuhansiin riveihin kestämättömästä sotkusta. Ollut siellä. ’ ei ole syntiä käyttää apuohjelmaluokkia ja palvelutasoa.
- Mielestäni jgauffin oli menossa siihen, että kysymys koskee MVC: tä. Jos suostumme tarkastelemaan järjestelmää MVC: n näkökulmasta ja vain MVC: n näkökulmasta, niin kyllä, kaikki liiketoimintalogiikat kuuluvat ” -malliin ”, mutta ” -malli ” voi käsittää useita luokkia ja tasoja, mukaan lukien ” hyötyluokat ” ja ” palvelutaso ” . Toisin sanoen emme ’ sanoisi, että palvelutaso on osa ohjainta tai näkymää, joten malli sopii parhaiten.
vastaus
Liikelogiikan sijoittaminen malliin saattaa kuulostaa parhaalta. Ohjain vastaanottaa puhelun etäverkkosovelluksesta. MVC-verkkopalvelun ohjain vie puhelun ja ohjaa suorituksen BL-menetelmään. Business Logic voi nyt sisältyä malliin, mutta se voidaan sijoittaa myös johonkin toiseen kansioon, esimerkiksi ”Business Logic” . Joten ei ole olemassa kovaa ja nopeaa sääntöä siitä, mihin liikelogiikka tulee olemaan.
Olen käyttänyt MVC 3.0: een rakennettua verkkopalvelua ja liiketoimintalogiikan säilö on MVC MALLI .
Kommentit
- Olen samaa mieltä. Saat paljon joustavamman sovelluksen, kun mallisi on yksinkertaisesti tietorakenne, jota muut liiketoimintalogiikkaluokat käyttävät. Yksinkertaisena esimerkkinä luulen, että tämä on suuri epäonnistuminen ASP.NET ’ -tarkastuskäytännössä määritteiden avulla. Jos merkitsen Henkilön ’ -nimi-ominaisuuden Pakollinen-määritteellä, mitä tapahtuu, jos luon järjestelmänvalvojanäkymän, jossa Etunimeä ei tarvita? Liikelogiikkakerroksen tulisi kuluttaa malli ja määrittää sille sopivat toimet.