A üzleti logikát a model , és kövér modellekre és sovány kontrollerekre kell törekednünk >.

Kiindulásként a vezérlő logikájából kell kiindulnunk. Például: a (z) frissítésnél, a vezérlőnek át kell irányítania a kódot a metódushoz / szolgáltatáshoz , amely átadja a módosításokat a modellen.

A modellben könnyen létrehozhatunk helper / service osztályok, ahol az alkalmazás üzleti szabályai vagy számításai érvényesíthetők.

Fogalmi összefoglaló

• A vezérlő az alkalmazás logikája. Az a logika, amely arra vonatkozik, hogy az alkalmazás miként akar interakcióba lépni a ” tudástartomány ” tartozik.

• A modell az alkalmazástól független logikához készült. Ennek a logikának érvényesnek kell lennie a ” tudástartomány minden lehetséges alkalmazásában “, amelyhez tartozik.

• Ezért logikus az összes üzleti szabály elhelyezése a modellben.

Megjegyzések

• szép világos és tömör válasz ..
• @ Yusubov, kérem, magyarázza el, mi a különbség az alkalmazáslogika és az üzleti logika között
• @Moh, Röviden összefoglalva ezek a segítő szavak ismertesse a technológia szintjeit egy alkalmazásban. Az üzleti logika alapvetően a rendszer szabályai a funkcionális specifikációk szerint. Például a B típusú A objektumnak C és D attribútumot kell tulajdonítania, de nem E elemet. Az alkalmazáslogika inkább technikai specifikáció, például Java szervleteket és OJB-t használ az Oracle adatbázis fenntartásához.
• részletezze ezeket a szavakat: 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]
• Ha jól értettem, az említett cikk ‘ alkalmazáslogikára ‘ ‘ üzleti logika ‘. Ezért semmit, ami az üzleti logikára utal, nem szabad elhelyezni a vezérlőben vagy a nézetben.

Mint mindig, ez a projekt összetettségétől függ.

Triviális alkalmazásokban, ahol a tartománymodell bonyolultsága viszonylag kicsi, a modellekbe beillesztheti a logikát, és egy napnak hívhatja.

Azonban nem triviális, összetett modelleket és sok üzleti szabályt tartalmazó alkalmazások esetében jobb egy kicsit jobban elkülöníteni a dolgokat.

Ha az üzleti logikát több modellt is magába foglalja, egy modellt, szoros összekapcsolást vezet be ezek között a modellek között.Amint az alkalmazások folyamatosan bővülnek, ezek a modellek hajlamosak god models vé válni, túl sokat tudva. Ez pedig gyorsan nagy rendetlenséggé válik, amelyet nehéz tesztelni és fenntartani. Tehát ebben az esetben előnyös, ha a logikát külön rétegbe rakja.

Az absztrakcióról való döntés során mindig vegye figyelembe az alkalmazás bonyolultságát és céljait, és kerülje a túltervezést. Triviális / kicsi alkalmazások esetén a szükségesnél több réteg bevitele növeli a bonyolultságot ahelyett, hogy csökkentené.

Robert Martin (Bob bácsi) jó blogbejegyzést ír erről a témáról: A tiszta építészet.

Hozzászólások

• a kérdés az MVC-re vonatkozott. az üzleti logikának mindig a modellben kell lennie. A vezérlő csak adapter.
• Az MVC az iparág egyik legjobban terhelt kifejezése. Nem ‘ nem akarok belemenni e kifejezés furcsaságaiba, mivel ez könyvet indokol. Az MVC használata nem jelenti azt, hogy minden logikát be kell illesztenie a modellekbe.
• Steve Burbeck (Smalltalk team) definíciója szerint: The controller interprets the mouse and keyboard inputs from the user, commanding the model and/or the view to change as appropriate. Ez ‘ egy adapterdefiníciót jelent.
• Ha az összes logikát beleteszi a modellbe, több ezer sornyi fenntarthatatlan rendetlenség lesz a végén. Ott volt. ‘ nem bűn, ha hasznossági osztályok és szolgáltatási réteg van.
• Úgy gondolom, hogy a jgauffin az volt, hogy a kérdés konkrét az MVC-re. Ha vállaljuk, hogy a rendszert az MVC és csak az MVC perspektívájából nézzük, akkor igen, az üzleti logika az ” modellbe tartozik “, de a ” modell ” több osztályt és réteget is felölelhet, beleértve a ” segédosztályok ” és ” egy szolgáltatási réteg ” . Másképp fogalmazva, nem mondanánk, hogy ‘ nem mondanánk, hogy a szolgáltatási réteg a vezérlő vagy a nézet része, ezért a legjobb illeszkedés a modell.

Az üzleti logika behelyezése a modellbe a legjobb út lehet. A vezérlő hívást fogad a távoli webalkalmazástól. Az MVC webszolgáltatás vezérlője átveszi a hívást és átirányítja a végrehajtást egy BL-metódusra. Mostantól az üzleti logika megtalálható a “modellben”, de elhelyezhető valamilyen más mappában is, mondjuk: “Üzleti logika” . Tehát nincs kemény és gyors szabály arra vonatkozóan, hogy hol lesz az üzleti logika.

Az MVC 3.0-ra épített webszolgáltatást használtam, és az üzleti logika tárolója az MVC MODEL .

Megjegyzések

• Egyetértek. Sokkal rugalmasabb alkalmazást kap, ha a modellje egyszerűen más üzleti logikai osztályok által működtetett adatszerkezet. Egyszerű példaként azt gondolom, hogy ez nagy kudarcot vall az ASP.NET ‘ attribútumok felhasználásával végzett validálási megközelítésében. Ha egy Személy ‘ tulajdonos tulajdonságát a Kötelező attribútummal jegyzem meg, mi történik, ha létrehozok egy rendszergazdai nézetet, ahol a Vezetéknév nem szükséges? Az üzleti logikai rétegnek fel kell használnia a modellt, és meg kell határoznia a megfelelő műveleteket.