Vytvořil jsem jednoduchou aplikaci MVC Java, která přidává záznamy prostřednictvím datových formulářů do databáze.
Moje aplikace shromažďuje data, také je ověřuje a ukládá. Důvodem je, že data jsou získávána online od různých uživatelů. data jsou většinou numerické povahy.
Nyní na číselných datech ukládaných do databáze (server SQL) chci, aby moje aplikace prováděla výpočty a zobrazovala výsledky. Uživatel nemá zájem o to, jak se výpočty provádějí, takže musí být zapouzdřeny. Uživatel musí být schopen zobrazit pouze jednoduchá vypočítaná data (například data sloupce A minus data sloupce B dělená daty sloupce C.) Vím, jak psát uložené procedury pro stejné, ale chci třívrstvou aplikaci.
Chci data, která jsem vložil do databáze jako záznam, na kterých jsem pracoval výpočty. Původní data by neměla zůstat ovlivněna, zatímco nová data, post-výpočty, musí být uložena jako nový záznam entity do databáze.
Kam mám napsat kód pro tento výpočet na pozadí? Jelikož se jedná o pravidla a obchodní logiku, měl bych je vložit do nových souborů JavaBeans?
Komentáře
- možný duplikát Při práci s databází zůstat OO a testovatelný
- Obchodní logika je alias člověka ve vašem týmu / oddělení, kterého se ptáte, jak na modelu pracovat. ‚ Proto může být obchodní logika uložena v oddělené třídě s názvem Obchodní logika. Totéž platí pro Presentation Logic, což je synonymum pro návrháře, který odpovídá na vaše otázky ohledně formátování nebo zobrazení komponent uživatelského rozhraní. Může existovat také vývojářská logika (otázky, které si kladete a odpovídáte sami nebo se ptáte svých kolegů), což představuje znalosti o tom, jak vytvořit a propojit součásti programu dohromady.
Odpověď
Obchodní logika by měla být umístěna do model a měli bychom se zaměřit na tlusté modely a hubené ovladače .
Jako výchozí bod bychom měli vycházet z logiky řadiče. Například: při aktualizaci by měl váš ovladač nasměrovat váš kód na metodu / službu , která přináší vaše změny modelu.
V modelu můžeme snadno vytvořit pomocníka / třídy služeb , kde lze ověřit obchodní pravidla nebo výpočty .
Koncepční shrnutí
-
Řadič je určen pro logiku aplikace. Logika, která je specifická pro to, jak chce vaše aplikace komunikovat s “ doménou znalostí „, kam patří.
-
Model je určen pro logiku, která je nezávislá na aplikaci . Tato logika by měla být platná ve všech možných aplikacích “ domény znalostí „, kam patří.
-
Je tedy logické umístit do modelu všechna obchodní pravidla.
Komentáře
- pěkná jasná a stručná odpověď ..
- @Yusubov, prosím, mohl byste mi vysvětlit rozdíl mezi aplikační logikou a obchodní logikou
- @Moh, Stručně řečeno, jsou to buzz slova, která vám pomohou popsat úrovně technologie v aplikaci. Obchodní logika je v zásadě pravidla systému podle funkčních specifikací. Například objekt A typu B musí mít přidělené C a D, ale ne E. Logika aplikací je spíše technickou specifikací, jako je použití servletů Java a OJB k přetrvávání v databázi Oracle.
- Prosím rozpracovat tato slova:
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] - Pokud jsem pochopil správně, zmiňovaný článek označuje ‚ aplikační logiku ‚ jako ‚ obchodní logika ‚. Cokoliv, co odkazuje na obchodní logiku, by proto nemělo být umístěno v řadiči nebo pohledu.
Odpovědět
Jako vždy to záleží na složitosti projektu.
V triviálních aplikacích, kde je složitost doménového modelu relativně malá, můžete logiku vložit do modelů a nazvat ji den.
U netriviálních aplikací se složitými modely a mnoha obchodními pravidly je však lepší oddělit věci o něco více.
Pokud vložíte obchodní logiku, která zahrnuje více než jeden model, model, zavádíte těsné propojení mezi těmito modely.Jak aplikace stále rostou, tyto modely mají tendenci se proměňovat v god models, protože toho vědí příliš mnoho. A to se rychle změní na velký nepořádek, který je těžké otestovat a udržovat. V takovém případě je výhodné logiku umístit do samostatné vrstvy.
Při rozhodování o abstrakci vždy berte v úvahu složitost a účely vaší aplikace a vyhněte se přílišnému inženýrství. U triviálních / malých aplikací zavedení více vrstev, než potřebuje, zvyšuje složitost místo toho, aby je snižovalo.
Robert Martin (strýček Bob) má na tento téma dobrý blogový příspěvek: Čistá architektura.
Komentáře
- otázka byla specifická pro MVC. obchodní logika by měla být vždy v modelu. Řadič je jen adaptér.
- MVC je jedním z nejvíce přetížených výrazů v oboru. Nechci ‚ se dostat do podivnosti tohoto termínu, protože to vyžaduje knihu. Pouhé použití MVC neznamená ‚, že musíte do modelů vložit veškerou logiku.
- Z definice Steva Burbecka (tým Smalltalk):
The controller interprets the mouse and keyboard inputs from the user, commanding the model and/or the view to change as appropriate. To ‚ je definice adaptéru. - Pokud vložíte veškerou logiku do modelu, skončíte s tisíci řádky neudržitelného nepořádku. Byl tam. ‚ Není hřích mít třídy nástrojů a vrstvu služeb.
- Myslím, že to, k čemu se jgauffin dostával, je, že otázka je specifická pro MVC. Pokud souhlasíme se zobrazením systému z pohledu MVC a pouze z pohledu MVC, pak ano, veškerá obchodní logika patří do “ modelu „, ale “ model “ může zahrnovat více tříd a vrstev, včetně “ třídy nástrojů “ a “ servisní vrstva “ . Jinými slovy bychom neřekli ‚, že servisní vrstva je součástí kontroleru nebo pohledu, proto je nejvhodnější model.
Odpověď
Vložení obchodní logiky do modelu může znít nejlepším způsobem. Řídicí jednotka přijme hovor ze vzdálené webové aplikace. Řadič ve webové službě MVC přijme volání a přesměruje provedení na metodu v BL. Nyní může být obchodní logika obsažena v „modelu“, ale může být také umístěna v jiné složce, například „Business Logic“ . Neexistuje tedy žádné pevné a rychlé pravidlo, kde bude obchodní logika.
Používal jsem webovou službu postavenou na MVC 3.0 a kontejner obchodní logiky je komentáře MVC MODEL .
Komentáře
- Souhlasím. Získáte mnohem flexibilnější aplikaci, když je váš model jednoduše datovou strukturou, na kterou reagují jiné třídy obchodní logiky. Jako jednoduchý příklad si myslím, že jde o velké selhání přístupu technologie ASP.NET ‚ k ověřování pomocí atributů. Pokud anotuji vlastnost First
s FirstName pomocí atributu Required, co se stane, když vytvořím zobrazení správce, kde by nemělo být vyžadováno FirstName? Vrstva obchodní logiky by měla model využívat a určit pro něj příslušné akce.