Jeg har opprettet et enkelt MVC Java-program som legger til poster gjennom dataskjemaer til en database.
Appen min samler inn data, den validerer den og lagrer den. Dette er fordi dataene hentes online fra forskjellige brukere. dataene er for det meste numeriske i naturen.
Nå når de numeriske dataene lagres i databasen (SQL server), vil jeg at appen min skal utføre beregninger og vise resultatene. Brukeren er ikke interessert i hvordan beregninger gjøres, så de må være innkapslet. Brukeren må bare kunne se de enkle beregnede dataene (for eksempel A-kolonnedata minus B Kolonnedata delt på C-kolonnedata). Jeg vet hvordan jeg skal skrive lagrede prosedyrer for det samme, men jeg vil ha en tredelt app.
Jeg vil ha dataene jeg legger inn i databasen som en post, bearbeidet ved å utføre beregninger på den. De opprinnelige dataene skal forbli upåvirket, mens de nye dataene, etter beregninger, må lagres som en ny enhetspost i databasen.
Hvor skal jeg skrive koden for denne bakgrunnsberegningen? Siden det er reglene og forretningslogikken, skal jeg legge den i nye JavaBeans-filer?
Kommentarer
- mulig duplikat av Forblir OO og kan testes mens du arbeider med en database
- Forretningslogikk er alias for en fyr i teamet / avdelingen som du spør hvordan du gjør / opererer på en modell. Det er ‘ hvorfor, Virksomhetslogikken kan lagres i en adskilt klasse som heter Forretningslogikk. Det samme gjelder Presentation Logic, som er et synonym for en designer fyr som svarer på spørsmålene dine om hvordan du formaterer eller viser UI-komponenter. Det kan også være en utviklerlogikk (spørsmål du stiller og svarer av deg selv eller stiller kollegaene dine) som representerer kunnskap om hvordan du oppretter og kobler en programkomponent sammen.
Svar
forretningslogikken bør plasseres i modell , og vi bør sikte mot fett modeller og tynne kontrollere .
Som utgangspunkt bør vi starte fra kontrollerlogikken. For eksempel: ved oppdatering , bør kontrolleren din lede koden din til metoden / tjenesten som leverer dine endringer i modellen.
I modellen kan vi enkelt lage hjelper / tjeneste klasser der applikasjonen forretningsregler eller beregninger kan valideres.
En konseptuell oppsummering
-
Kontrolleren er for applikasjonslogikk. Logikken som er spesifikk for hvordan søknaden din vil samhandle med » kunnskapsdomene » den tilhører.
-
-modellen er for logikk som er uavhengig av applikasjonen . Denne logikken skal være gyldig i alle mulige anvendelser av » kunnskapsdomene » den tilhører.
-
Dermed er det logisk å plassere alle forretningsregler i modellen.
Kommentarer
- fint, tydelig og kortfattet svar ..
- @Yusubov, kan du forklare meg forskjellen mellom applikasjonslogikken og forretningslogikken
- @Moh, kort sagt er dette ord som hjelper beskrive nivåer av teknologi i en applikasjon. Forretningslogikk er i utgangspunktet systemets regler i henhold til funksjonelle spesifikasjoner. For eksempel må objekt A av type B ha tilskrevet C og D, men ikke E. Application Logic er mer en teknisk spesifikasjon, som å bruke Java-servlets og OJB for å fortsette til en Oracle-database.
- Vil du behage utdyp disse ordene:
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] - Hvis jeg forsto riktig, refererer nevnte artikkel til ‘ applikasjonslogikk ‘ som en ‘ forretningslogikk ‘. Dermed bør ikke alt som refererer til forretningslogikken plasseres i kontrolleren eller visningen.
Svar
Som alltid avhenger det av kompleksiteten i prosjektet.
I trivielle applikasjoner, der domenemodellkompleksiteten er relativt liten, kan du legge logikken i modellene og kalle den en dag.
For ikke trivielle applikasjoner med komplekse modeller og mange forretningsregler er det imidlertid bedre å skille ting litt mer.
Hvis du legger inn forretningslogikken som involverer mer enn en modell i en modell, introduserer du en tett kobling mellom disse modellene.Etter hvert som applikasjonene fortsetter å vokse, har disse modellene en tendens til å bli til god models, og vite for mye. Og dette blir raskt til et stort rot som er vanskelig å teste og vedlikeholde. Så i så fall er det fordelaktig å sette logikken i et eget lag.
Når du bestemmer deg for abstraksjon, må du alltid ta hensyn til appens kompleksitet og formål, og unngå overteknikk. For trivielle / små applikasjoner, introduserer flere lag enn det trenger, øker kompleksiteten i stedet for å redusere den.
Robert Martin (onkel Bob) har et godt blogginnlegg om dette emnet: The Clean Architecture.
Kommentarer
- spørsmålet var spesifikt for MVC. forretningslogikk skal alltid være i modellen. Kontrolleren er bare en adapter.
- MVC er en av de mest overbelastede vilkårene i bransjen. Jeg vil ikke ‘ ikke komme inn i særegenheter i dette begrepet, da det garanterer en bok. Bare å bruke MVC betyr ikke ‘ t at du må sette alle logikkene i modellene.
- Fra definisjonen av Steve Burbeck (Smalltalk team):
The controller interprets the mouse and keyboard inputs from the user, commanding the model and/or the view to change as appropriate. At ‘ er en adapterdefinisjon. - Hvis du legger all logikken i modellen, vil du ende opp med tusenvis av linjer med uvedlikeholdelig rot. Vært der. Det ‘ er ikke synd å ha bruksklasser og et tjenestelag.
- Jeg tror det jgauffin kom til er at spørsmålet er spesifikt for MVC. Hvis vi er enige om å se systemet fra MVC-perspektivet og kun MVC-perspektivet, så ja, all forretningslogikken hører hjemme i » -modellen «, men » -modellen » kan omfatte flere klasser og lag, inkludert » verktøyklasser » og » et tjenestelag » . For å si det på en annen måte, ville vi ikke ‘ ikke si at tjenestelaget er en del av kontrolleren eller visningen, derfor er den beste passformen modellen.
Svar
Det kan høres den beste måten å legge forretningslogikken inn i modellen. Kontrolleren mottar et anrop fra den eksterne nettappen. Kontrolleren på MVC-nettjenesten tar samtalen og omdirigerer kjøringen til en metode i BL. Nå kan Business Logic være inneholdt i «Model», men kan også plasseres i en annen mappe, si «Business Logic» . Så det er ingen hard og rask regel om hvor forretningslogikken skal være.
Jeg har brukt en nettjeneste bygget på MVC 3.0, og beholderen med forretningslogikk er MVC MODELL .
Kommentarer
- Jeg er enig. Du får en mye mer fleksibel applikasjon når modellen din bare er en datastruktur som handles av andre forretningslogikklasser. Som et enkelt eksempel, tror jeg det er en stor feil ved ASP.NET ‘ s tilnærming til validering ved hjelp av attributter. Hvis jeg kommenterer en person ‘ s FirstName-egenskap med attributtet Obligatorisk, hva skjer hvis jeg oppretter en administratorvisning der FirstName ikke skal kreves? Et forretningslogisk lag skal konsumere modellen og bestemme passende handlinger for den.