Jeg har oprettet et simpelt MVC Java-program, der tilføjer poster gennem dataformularer til en database.
Min app indsamler data, den validerer dem også og gemmer dem. Dette skyldes, at data hentes online fra forskellige brugere. dataene er for det meste numeriske.
Nu når de numeriske data gemmes i databasen (SQL-server), vil jeg have, at min app skal udføre beregninger og vise resultaterne. Brugeren er ikke interesseret i, hvordan beregninger udføres, så de skal indkapsles. Brugeren skal kun kunne se de simple beregnede data (for eksempel A-kolonnedata minus B Kolonnedata divideret med C-kolonnedata). Jeg ved, hvordan man skriver lagrede procedurer til det samme, men jeg vil have en tre-trins app.
Jeg vil have de data, som jeg lægger i databasen som en post, bearbejdet ved at udføre beregninger på den. De originale data skal forblive upåvirket, mens de nye data, efter beregninger, skal gemmes som en ny enhedsregistrering i databasen.
Hvor skal jeg skrive koden til denne baggrundsberegning? Da det er reglerne og forretningslogikken, skal jeg placere det i nye JavaBeans-filer?
Kommentarer
- mulig duplikat af Forbliver OO og testbart, mens du arbejder med en database
- Forretningslogik er alias for en fyr i dit team / afdeling, som du spørger, hvordan man laver / opererer på en model. Derfor er ‘ Forretningslogikken lagret i en adskilt klasse med navnet Forretningslogik. Det samme gælder for præsentationslogik, der er et synonym for en designer fyr, der besvarer dine spørgsmål om, hvordan man formaterer eller viser UI-komponenter. Der kan også være en Developer Logic (spørgsmål, som du selv stiller og besvarer eller stiller dine kolleger), der repræsenterer en viden om, hvordan man opretter og forbinder en programkomponenter sammen.
Svar
forretningslogik skal placeres i model , og vi skal sigte mod fede modeller og tynde controllere .
Som startpunkt skal vi starte fra controllerens logik. For eksempel: ved opdatering , skal din controller dirigere din kode til metode / service som leverer dine ændringer til modellen.
I modellen kan vi let oprette hjælper / service klasser, hvor applikationen forretningsregler eller beregninger kan valideres.
En konceptuel resume
-
Controlleren er til applikationslogik. Logikken, der er specifik for, hvordan din applikation ønsker at interagere med det ” vidensdomæne “, det hører til.
-
-modellen er til logik, der er uafhængig af applikationen . Denne logik skal være gyldig i alle mulige anvendelser af ” vidensdomæne ” den tilhører.
-
Det er således logisk at placere alle forretningsregler i modellen.
Kommentarer
- pænt klart og kortfattet svar ..
- @Yusubov, bedes du forklare mig forskellen mellem applikationslogikken og forretningslogikken
- @Moh, kort sagt er dette buzz-ord til hjælp beskrive teknologieniveauer i en applikation. Forretningslogik er grundlæggende regler i systemet i henhold til funktionelle specifikationer. F.eks. Skal objekt A af type B have tilskrevet C og D, men ikke E. Application Logic er mere en teknisk specifikation, som at bruge Java-servlets og OJB til at fortsætte til en Oracle-database.
- Vil du gerne uddybe disse ord:
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 forstod rigtigt, henviser den nævnte artikel til ‘ applikationslogik ‘ som en ‘ forretningslogik ‘. Alt, der henviser til forretningslogikken, bør således ikke placeres i controlleren eller visningen.
Svar
Som altid afhænger det af projektets kompleksitet.
I trivielle applikationer, hvor domænemodelens kompleksitet er relativt lille, kan du sætte logikken i modellerne og kalde det en dag.
For ikke trivielle applikationer med komplekse modeller og masser af forretningsregler er det dog bedre at adskille tingene lidt mere.
Hvis du lægger den forretningslogik, der involverer mere end en model i en model introducerer du en tæt kobling mellem disse modeller.Da applikationer fortsætter med at vokse, har disse modeller tendens til at blive til god models, idet de ved for meget. Og dette bliver hurtigt til et stort rod, der er svært at teste og vedligeholde. Så i så fald er det fordelagtigt at sætte logikken i et separat lag.
Når du beslutter dig for abstraktion, skal du altid tage din apps kompleksitet og formål i betragtning og undgå overteknik. For trivielle / små applikationer øger indførelsen af flere lag, end det har brug for, kompleksiteten i stedet for at reducere det.
Robert Martin (onkel Bob) har et godt blogindlæg om dette emne: Den rene arkitektur.
Kommentarer
- spørgsmålet var specifikt for MVC. forretningslogik skal altid være i modellen. Controlleren er bare en adapter.
- MVC er et af de mest overbelastede vilkår i branchen. Jeg vil ikke ‘ ikke komme ind i dette udtryks besvarelser, da det berettiger en bog. Bare ved at bruge MVC betyder ikke ‘ ikke, at du skal sætte enhver logik i modellerne.
- Fra definitionen af 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 adapterdefinition. - Hvis du lægger al logik i modellen, vil du ende med tusindvis af linjer med uvedligeholdeligt rod. Været der. Det ‘ er ikke en synd at have hjælpeklasser og et servicelag.
- Jeg tror, hvad jgauffin var ved at være, at spørgsmålet er specifikt for MVC. Hvis vi er enige om at se systemet fra MVC-perspektivet og kun MVC-perspektivet, så ja, hele forretningslogikken hører til i ” -modellen “, men ” -modellen ” kan omfatte flere klasser og lag inklusive ” hjælpeklasser ” og ” et servicelag ” . For at sige det på en anden måde ville vi ikke ‘ ikke sige, at servicelaget er en del af controlleren eller visningen, derfor er modellen den bedste pasform.
Svar
At lægge forretningslogikken inde i modellen lyder måske den bedste vej at gå. Controlleren modtager et opkald fra den eksterne webapp. Controlleren på MVC-webservicen tager opkaldet og omdirigerer udførelsen til en metode i BL. Nu kan Business Logic være indeholdt i “Model”, men kan også placeres i en anden mappe, f.eks. “Business Logic” . Så der er ingen hård og hurtig regel om, hvor forretningslogikken skal være.
Jeg har brugt en webservice bygget på MVC 3.0, og beholderen med forretningslogik er MVC MODEL .
Kommentarer
- Jeg er enig. Du får en meget mere fleksibel applikation, når din model simpelthen er en datastruktur, der handles af andre forretningslogikklasser. Som et simpelt eksempel synes jeg, det er en stor fejl i ASP.NET ‘ s tilgang til validering ved hjælp af attributter. Hvis jeg kommenterer en persons ‘ s FirstName-egenskab med attributten Obligatorisk, hvad sker der, hvis jeg opretter en administratorvisning, hvor FirstName ikke skal kræves? Et forretningslogiklag skal forbruge modellen og bestemme de relevante handlinger til den.