Ik heb een eenvoudige MVC Java-applicatie gemaakt die records via gegevensformulieren aan een database toevoegt.
Mijn app verzamelt gegevens, valideert deze en slaat ze op. Dit komt doordat de gegevens online van verschillende gebruikers worden gehaald. de gegevens zijn meestal numeriek van aard.
Nu de numerieke gegevens in de database (SQL-server) worden opgeslagen, wil ik dat mijn app berekeningen uitvoert en de resultaten weergeeft. De gebruiker is niet geïnteresseerd in hoe berekeningen worden uitgevoerd, dus moeten ze worden ingekapseld. De gebruiker mag alleen de eenvoudig berekende gegevens kunnen zien (bijvoorbeeld A-kolomgegevens minus B-kolomgegevens gedeeld door C-kolomgegevens). Ik weet hoe ik daarvoor opgeslagen procedures moet schrijven, maar ik wil een app met drie niveaus.
Ik wil dat de gegevens die ik als een record in de database plaats, aan de slag gaan door er berekeningen op uit te voeren. De originele gegevens moeten onaangetast blijven, terwijl de nieuwe gegevens, na berekeningen, moeten worden opgeslagen als een nieuw entiteitsrecord in de database.
Waar moet ik de code voor deze achtergrondberekening schrijven? Moet ik het in nieuwe JavaBeans-bestanden plaatsen, aangezien het de regels en bedrijfslogica zijn?
Opmerkingen
- mogelijk duplicaat van OO en testbaar blijven terwijl je met een database werkt
- Bedrijfslogica is een alias voor een man in je team / afdeling die je vraagt hoe je een model moet uitvoeren / gebruiken. Dat ‘ is waarom, de bedrijfslogica kan worden opgeslagen in een aparte klasse genaamd Bedrijfslogica. Hetzelfde geldt voor Presentation Logic, een synoniem voor een ontwerper die uw vragen beantwoordt over het opmaken of weergeven van UI-componenten. Er kan ook een ontwikkelaarslogica zijn (vragen die u zelf stelt en beantwoordt of die u aan uw collegas stelt) die kennis vertegenwoordigt over het maken en verbinden van programmaonderdelen.
Answer
De bedrijfslogica moet in de model , en we zouden moeten mikken op dikke modellen en magere controllers .
Om te beginnen moeten we uitgaan van de controllerlogica. Bijvoorbeeld: bij update , je controller moet je code naar de methode / service sturen die levert uw wijzigingen aan het model.
In het model kunnen we gemakkelijk helper / service klassen waar de applicatie bedrijfsregels of berekeningen kan worden gevalideerd.
Een conceptueel samenvatting
-
De controller is voor applicatielogica. De logica die specifiek is voor hoe uw applicatie wil communiceren met het ” kennisdomein ” het hoort erbij.
-
Het -model is voor logica die onafhankelijk is van de toepassing . Deze logica moet geldig zijn in alle mogelijke toepassingen van het ” kennisdomein ” het behoort.
-
Het is dus logisch om alle bedrijfsregels in het model te plaatsen.
Opmerkingen
- mooi duidelijk en beknopt antwoord.
- @Yusubov, zou je me alsjeblieft het verschil kunnen uitleggen tussen de applicatielogica en de bedrijfslogica
- @Moh, kortom dit zijn buzzwoorden om te helpen beschrijf technologielagen in een applicatie. Bedrijfslogica is in feite regels van het systeem volgens functionele specificaties. Object A van type B moet bijvoorbeeld C en D hebben toegekend, maar niet E. Application Logic is meer een technische specificatie, zoals het gebruik van Java-servlets en OJB om te blijven bestaan in een Oracle-database.
- Wilt u alstublieft licht deze woorden toe:
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] - Als ik het goed heb begrepen, verwijst het genoemde artikel naar ‘ toepassingslogica ‘ als een ‘ bedrijfslogica ‘. Dus alles wat verwijst naar de bedrijfslogica mag niet in de controller of de weergave worden geplaatst.
Answer
Zoals altijd hangt het af van de complexiteit van het project.
In triviale toepassingen, waar de complexiteit van het domeinmodel relatief klein is, kun je de logica in de modellen stoppen en er een einde aan maken.
Voor niet-triviale applicaties met complexe modellen en veel bedrijfsregels is het echter beter om de dingen een beetje meer te scheiden.
Als u de bedrijfslogica die meer dan één model omvat, in een model, introduceer je een nauwe koppeling tussen die modellen.Naarmate applicaties blijven groeien, neigen deze modellen te veranderen in god models, omdat ze te veel weten. En dit zal snel veranderen in een grote puinhoop die moeilijk te testen en te onderhouden is. In dat geval is het dus handig om de logica in een aparte laag te plaatsen.
Houd bij het beslissen over abstractie altijd rekening met de complexiteit en doelen van je app, en vermijd over-engineering. Voor triviale / kleine toepassingen zorgt de introductie van meer lagen dan nodig voor een grotere complexiteit in plaats van een vermindering.
Robert Martin (oom Bob) heeft een goede blogpost over dit onderwerp: The Clean Architecture.
Opmerkingen
- de vraag was specifiek voor MVC. bedrijfslogica moet altijd in het model zitten. De controller is slechts een adapter.
- MVC is een van de meest overbelaste termen in de branche. Ik ‘ wil niet in de eigenaardigheden van deze term komen, omdat het een boek rechtvaardigt. Alleen het gebruik van MVC impliceert niet ‘ t dat je elke logica in de modellen moet stoppen.
- Uit de definitie van 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. Dat ‘ is een adapterdefinitie. - Als je alle logica in het model stopt, zul je eindigen met duizenden regels onhoudbare rotzooi. Ben daar geweest. Het ‘ is geen zonde om utility-klassen en een servicelaag te hebben.
- Ik denk dat jgauffin bedoelde dat de vraag specifiek is voor MVC. Als we ermee instemmen om het systeem vanuit het MVC-perspectief te bekijken en alleen vanuit het MVC-perspectief, ja, dan hoort alle bedrijfslogica thuis in het ” -model “, maar het ” model ” kan bevatten meerdere klassen en lagen, waaronder ” utility classes ” en ” een servicelaag ” . Om het anders te zeggen, we zouden niet ‘ zeggen dat de servicelaag een onderdeel is van de controller of view, daarom past het model het beste.
Answer
De bedrijfslogica in het model plaatsen klinkt misschien de beste manier om te gaan. De controller ontvangt een oproep van de externe webapp. De controller op de MVC-webservice neemt de oproep aan en leidt de uitvoering om naar een methode in BL. Business Logic kan nu worden opgenomen in het “Model”, maar kan ook in een andere map worden geplaatst, bijvoorbeeld “Business Logic” . Er is dus geen vaste regel over waar de bedrijfslogica zal zijn.
Ik heb een webservice gebruikt die is gebouwd op MVC 3.0 en de container van bedrijfslogica is de MVC MODEL .
Reacties
- Ik ben het ermee eens. U krijgt een veel flexibelere toepassing wanneer uw model eenvoudigweg een gegevensstructuur is waarop wordt gehandeld door andere bedrijfslogica-klassen. Als een eenvoudig voorbeeld denk ik dat dit een grote mislukking is van ASP.NET ‘ s benadering van validatie met behulp van attributen. Als ik de eigenschap FirstName van een Persoon ‘ s FirstName annoteer met het kenmerk Vereist, wat gebeurt er dan als ik een beheerdersweergave maak waarin FirstName niet vereist zou moeten zijn? Een bedrijfslogica-laag moet het model consumeren en de geschikte acties ervoor bepalen.