Jag har skapat en enkel MVC Java-applikation som lägger till poster genom dataformulär till en databas.
Min app samlar in data, den validerar den och lagrar den. Detta beror på att data hämtas online från olika användare. uppgifterna är mestadels numeriska till sin natur.
Nu när de numeriska data lagras i databasen (SQL-server) vill jag att min app ska utföra beräkningar och visa resultaten. Användaren är inte intresserad av hur beräkningar görs så de måste inkapslas. Användaren måste endast kunna se de enkla beräknade uppgifterna (till exempel A-kolumndata minus B-kolumndata dividerat med C-kolumndata). Jag vet hur man skriver lagrade procedurer för samma men jag vill ha en app med tre nivåer.
Jag vill att de data som jag lägger in i databasen som en post, bearbetas genom att utföra beräkningar på den. De ursprungliga uppgifterna ska förbli opåverkade, medan de nya uppgifterna, efter beräkningarna, måste lagras som en ny entitetspost i databasen.
Var ska jag skriva koden för denna bakgrundsberäkning? Eftersom det är reglerna och affärslogiken, ska jag lägga det i nya JavaBeans-filer?
Kommentarer
- möjlig duplikat av Att vara OO och testas när du arbetar med en databas
- Affärslogik är alias för en kille i ditt team / avdelning som du frågar hur man gör / använder en modell. Därför ’ är det därför affärslogiken kan lagras i en separat klass med namnet Affärslogik. Detsamma gäller Presentation Logic, som är en synonym för en designer-kille som svarar på dina frågor om hur man formaterar eller visar UI-komponenter. Det kan också finnas en utvecklarlogik (frågor som du ställer och svarar själv eller ställer dina kollegor) som representerar en kunskap om hur man skapar och kopplar samman en programkomponent.
Svar
affärslogik bör placeras i modell , och vi borde sikta på feta modeller och smala -kontroller .
Som utgångspunkt bör vi börja från styrlogiken. Till exempel: vid uppdatering , ska din controller styra din kod till metod / tjänst som levererar dina ändringar i modellen.
I modellen kan vi enkelt skapa hjälpare / tjänst klasser där applikationen affärsregler eller beräkningar kan valideras.
En konceptuell sammanfattning
-
Styrenheten är för applikationslogik. Logiken som är specifik för hur din applikation vill interagera med ” kunskapsdomän ” den tillhör.
-
-modellen är för logik som är oberoende av applikationen . Denna logik bör vara giltig i alla möjliga tillämpningar av ” kunskapsdomän ” den tillhör.
-
Det är alltså logiskt att placera alla affärsregler i modellen.
Kommentarer
- trevligt klart och koncist svar ..
- @Yusubov, snälla kan du förklara mig skillnaden mellan applikationslogiken och affärslogiken
- @Moh, kort sagt, det här är ord som hjälper beskriva tekniknivåer i en applikation. Affärslogik är i grunden regler i systemet enligt funktionsspecifikationer. Exempelvis måste objekt A av typ B ha tillskrivit C och D, men inte E. Application Logic är mer av en teknisk specifikation, som att använda Java-servlets och OJB för att fortsätta till en Oracle-databas.
- Vill du utarbeta dessa 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] - Om jag förstod rätt hänvisar nämnda artikel till ’ applikationslogik ’ som en ’ affärslogik ’. Således bör allt som hänvisar till affärslogiken inte placeras i kontrollenheten eller i vyn.
Svar
Som alltid beror det på komplexiteten i projektet.
I triviala applikationer, där domänmodellens komplexitet är relativt liten, kan du lägga in logiken i modellerna och kalla den en dag.
För icke triviala applikationer med komplexa modeller och många affärsregler är det dock bättre att skilja saker lite mer.
Om du lägger in den affärslogik som involverar mer än en modell i en modell introducerar du en tät koppling mellan dessa modeller.När applikationer fortsätter att växa tenderar dessa modeller att förvandlas till god models, eftersom de vet för mycket. Och detta blir snabbt en stor röra som är svår att testa och underhålla. Så i så fall är det fördelaktigt att placera logiken i ett separat lager.
När du bestämmer dig för abstraktion, ta alltid hänsyn till din appkomplexitet och syften och undvik överteknik. För triviala / små applikationer ökar komplexiteten istället för att minska den genom att införa fler lager än vad den behöver.
Robert Martin (farbror Bob) har ett bra blogginlägg om detta ämne: The Clean Architecture.
Kommentarer
- frågan var specifik för MVC. affärslogik bör alltid finnas i modellen. Styrenheten är bara en adapter.
- MVC är en av de mest överbelastade termerna i branschen. Jag vill inte ’ inte komma in i besvären från denna term, eftersom det berättigar till en bok. Att bara använda MVC betyder inte ’ t att du måste sätta alla logik i modellerna.
- Från definitionen 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. Att ’ är en adapterdefinition. - Om du lägger in all logik i modellen kommer du att få tusentals rader av ohållbar röra. Varit där. Det ’ är inte synd att ha verktygsklasser och ett servicelager.
- Jag tror vad jgauffin var ute efter är att frågan är specifik för MVC. Om vi är överens om att se systemet från MVC-perspektivet och endast MVC-perspektivet, så ja, all affärslogik hör hemma i ” -modellen ”, men ” -modellen ” kan omfatta flera klasser och lager, inklusive ” verktygsklasser ” och ” ett servicelager ” . För att uttrycka det på ett annat sätt skulle vi inte ’ säga att servicelagret är en del av styrenheten eller vyn, därför är den bästa passformen modellen.
Svar
Att sätta affärslogiken inuti modellen kanske låter det bästa sättet att gå. Styrenheten tar emot ett samtal från fjärrwebappen. Styrenheten på MVC-webbtjänsten tar samtalet och omdirigerar körningen till en metod i BL. Nu kan Business Logic ingå i ”Model”, men kan också placeras i någon annan mapp, säg ”Business Logic” . Så det finns ingen svår och snabb regel om var affärslogiken kommer att vara.
Jag har använt en webbtjänst byggd på MVC 3.0 och behållaren för affärslogik är MVC MODELL .
Kommentarer
- Jag håller med. Du får en mycket mer flexibel applikation när din modell helt enkelt är en datastruktur som hanteras av andra affärslogikklasser. Som ett enkelt exempel tror jag att det är ett stort misslyckande i ASP.NET ’ s metod för validering genom att använda attribut. Om jag antecknar en persons ’ s FirstName-egenskap med attributet Obligatoriskt, vad händer om jag skapar en adminvy där FirstName inte ska krävas? Ett affärslogiklager ska konsumera modellen och bestämma lämpliga åtgärder för den.