Am creat o aplicație Java MVC simplă care adaugă înregistrări prin formulare de date într-o bază de date.
Aplicația mea colectează date, le validează și le stochează. Acest lucru se datorează faptului că datele sunt obținute online de la diferiți utilizatori. datele sunt în mare parte de natură numerică.
Acum, pe baza datelor numerice stocate în baza de date (server SQL), vreau ca aplicația mea să efectueze calcule și să afișeze rezultatele. Utilizatorul nu este interesat de modul în care se fac calculele, astfel încât acestea trebuie încapsulate. Utilizatorul trebuie să poată vizualiza doar datele simple calculate (de exemplu, datele coloanei A minus B Datele coloanei împărțite la datele coloanei C). Știu cum să scriu proceduri stocate pentru aceleași, dar vreau o aplicație pe trei niveluri.
Vreau datele pe care le-am introdus în baza de date ca o înregistrare, la care să se efectueze calcule. Datele originale ar trebui să rămână neafectate, în timp ce noile date, după calcule, trebuie stocate ca o nouă înregistrare de entitate în baza de date.
Unde ar trebui să scriu codul pentru acest calcul de fundal? Întrucât este regulile și logica de afaceri, ar trebui să o pun în fișiere JavaBeans noi?
Comentarii
- posibil duplicat al Rămâneți OO și testabil în timp ce lucrați cu o bază de date
- Logica afacerii este un pseudonim pentru un tip din echipa / departamentul dvs. pe care îl întrebați cum să faceți / să operați pe un model. De aceea, ‘ este motivul pentru care logica Business poate fi stocată într-o clasă separată numită Business logic. Același lucru este valabil și pentru Logica de prezentare, care este un sinonim pentru un tip de designer care răspunde la întrebările dvs. despre cum să formatați sau să afișați componentele UI. Poate exista, de asemenea, o logică pentru dezvoltatori (întrebări pe care le puneți și le răspundeți de sine sau le puneți colegilor), care reprezintă o cunoaștere despre cum să creați și să conectați componentele unui program împreună.
Răspuns
logica de afaceri trebuie plasată în model și ar trebui să vizăm modele grase și controlere slabe .
Ca punct de pornire, ar trebui să pornim de la logica controlerului. De exemplu: la actualizare , controlorul dvs. ar trebui să vă direcționeze codul către metoda / serviciul care furnizează modificările dvs. la model.
În model, putem crea cu ușurință helper / service clase în care aplicația reguli de afaceri sau calcule pot fi validate.
Un concept rezumat
-
Controlerul este pentru logica aplicației. Logica specifică modului în care aplicația dvs. dorește să interacționeze cu ” domeniul de cunoaștere ” de care aparține.
-
Modelul este pentru logica care este independentă de aplicația . Această logică ar trebui să fie valabilă în toate aplicațiile posibile ale ” domeniu de cunoaștere ” de care aparține.
-
Astfel, este logic să plasați toate regulile de afaceri în model.
Comentarii
- un răspuns clar și concis ..
- @Yusubov, vă rog să-mi explicați diferența dintre logica aplicației și logica de afaceri
- @Moh, pe scurt, acestea sunt cuvinte buzz pentru a ajuta descrie niveluri de tehnologie într-o aplicație. Logica de afaceri este practic reguli ale sistemului conform specificațiilor funcționale. De exemplu Obiectul A de tip B trebuie să fi atribuit C și D, dar nu E. Logica aplicației este mai mult o specificație tehnică, cum ar fi utilizarea servleturilor Java și OJB pentru a persista într-o bază de date Oracle.
- elaborează aceste cuvinte:
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] - Dacă am înțeles corect, articolul menționat se referă la ‘ logica aplicației ‘ ca ‘ logică de afaceri ‘. Astfel, orice lucru care se referă la logica de afaceri nu trebuie plasat în controler sau în vizualizare.
Răspuns
Ca întotdeauna, depinde de complexitatea proiectului.
În aplicațiile banale, unde complexitatea modelului de domeniu este relativ mică, puteți pune logica în modele și o puteți numi o zi.
Cu toate acestea, pentru aplicații non-banale cu modele complexe și o mulțime de reguli de afaceri, este mai bine să separați lucrurile puțin mai mult.
Dacă puneți logica de afaceri care implică mai multe modele în un model, introduceți o cuplare strânsă între aceste modele.Pe măsură ce aplicațiile continuă să crească, aceste modele tind să se transforme în god models, știind prea multe. Și acest lucru se va transforma rapid într-o mare mizerie greu de testat și întreținut. Deci, în acest caz, este benefic să puneți logica într-un strat separat.
Atunci când vă decideți despre abstractizare, luați întotdeauna în considerare complexitatea și scopurile aplicației dvs. și evitați supra-ingineria. Pentru aplicații banale / mici, introducerea mai multor straturi decât are nevoie crește complexitatea în loc să o reducă.
Robert Martin (Unchiul Bob) are o postare bună pe acest subiect: The Clean Architecture.
Comentarii
- întrebarea a fost specifică pentru MVC. logica de afaceri ar trebui să fie întotdeauna în model. Controlerul este doar un adaptor.
- MVC este unul dintre cei mai supraîncărcați termeni din industrie. Nu ‘ nu vreau să intru în ciudățeniile acestui termen, deoarece justifică o carte. Doar că utilizarea MVC nu ‘ nu implică faptul că trebuie să introduceți fiecare logică în modele.
- Din definiția de Steve Burbeck (echipa Smalltalk):
The controller interprets the mouse and keyboard inputs from the user, commanding the model and/or the view to change as appropriate. Aceasta ‘ este o definiție a adaptorului. - Dacă puneți toată logica în model, veți ajunge cu mii de linii de mizerie de neînțeles. Am fost acolo. ‘ nu este un păcat să ai clase de utilități și un strat de servicii.
- Cred că la ce se confrunta jgauffin este că întrebarea este specifică pentru MVC. Dacă suntem de acord să vizualizăm sistemul din perspectiva MVC și numai din perspectiva MVC, atunci da, toată logica afacerii aparține modelului ” „, dar modelul ” ” poate cuprinde mai multe clase și straturi, inclusiv ” clase de utilitate ” și ” un strat de serviciu ” . Pentru a o spune altfel, nu am ‘ să spunem că stratul de serviciu este o parte a controlerului sau a vizualizării, prin urmare cea mai bună potrivire este modelul.
Răspuns
Introducerea logicii de afaceri în interiorul modelului poate suna cel mai bun mod de a merge. Controlerul primește un apel de la aplicația web la distanță. Controlerul serviciului web MVC preia apelul și redirecționează execuția către o metodă din BL. Acum, Business Logic poate fi conținut în „Model”, dar poate fi, de asemenea, poziționat într-un alt dosar, să zicem „Business Logic” . Deci, nu există o regulă rapidă și rapidă despre locul în care va fi logica de afaceri.
Am folosit un serviciu web construit pe MVC 3.0, iar containerul logicii de afaceri este MVC MODEL .
Comentarii
- Sunt de acord. Veți obține o aplicație mult mai flexibilă atunci când modelul dvs. este pur și simplu o structură de date acționată de alte clase de logică de afaceri. Ca un exemplu simplu, cred că este un mare eșec al abordării ASP.NET ‘ a validării prin utilizarea atributelor. Dacă adnot proprietatea FirstName a unei persoane ‘ cu atributul Obligatoriu, ce se întâmplă dacă creez o vizualizare de administrator în care nu ar trebui să fie necesar FirstName? Un strat de logică de afaceri ar trebui să consume modelul și să determine acțiunile adecvate pentru acesta.