it-swarm-eu.dev

Kolik obchodní logiky by mělo být dovoleno existovat ve vrstvě řadiče?

Někdy máme v řídícím kódu našich aplikací nějakou obchodní logiku. Toto je obvykle logika, která odlišuje, jaké metody volat z modelu a/nebo jaké argumenty je předat.

Dalším příkladem je sada obslužných funkcí, které existují v řadiči, které mohou pracovat na formátování nebo dezinfikování dat vrácených z modelu podle sady obchodních pravidel.

Funguje to, ale zajímalo by mě, jestli je to flirtování s katastrofou. Pokud je mezi řídicí jednotkou a modelem sdílená obchodní logika, tyto dvě vrstvy již nejsou oddělitelné a někdo zděděný kód může být touto nerovnoměrností v umístění kódu související s obchodní logikou zmaten.

Moje otázka zní, kolik obchodní logiky by mělo být povoleno v kontroléru a za jakých okolností, pokud existují?

41
jellyfishtree

V ideálním případě žádné

Ale to není vždy možné. Nemohu vám dát tvrdá čísla jako 20% nebo 10 řádků, což je subjektivní do té míry, že na ni nelze odpovědět. Dokážu popsat, jak používám návrhové vzory a okolnosti, které je vyžadují mírně ohýbat.

Podle mého názoru je to zcela na účelu aplikace. Vytváření jednoduchých REST api, které chcete zveřejnit? Zapomněli jste na čisté oddělení nebo dokonce na vzor. Můžete vypálit funkční verzi za hodinu. Budování něčeho většího? Pravděpodobně nejlepší na tom pracovat.

Cílem je budování individuálně obsažených systémů. Pokud začnete psát obchodní logiku, která je specifická pro to, jak dva systémy interagují, je to problém. Aniž bych se na to dál díval, nemohu vyjádřit názor.

Designové vzory jsou formy, některé je rádi striktně dodržují na základě principu a dobře napsaného kódu. Přísné dodržování vzoru vám pravděpodobně nedá špatný kód, ale může to zabrat více času a způsobit, že budete psát mnohem více kód.

Designové vzory jsou flexibilní, upravte je tak, aby vyhovovaly vašim potřebám. Ohněte je příliš mnoho a oni se ale zlomí. Víte, co potřebujete a vyberte vzorec vzoru, který je k tomu nejblíže.

22
Josh K

Tak málo, jak je to možné. Nejlépe žádné.

Řadič by se měl zabývat přijetím žádosti, žádáním správné doménové služby, aby žádost zpracoval, a předáním odpovědi na správné zobrazení.

V tomto procesu by veškerá „obchodní logika“ měla existovat v doménových službách.

Pokud máte funkčnost, která z nich odebírá doménové objekty a vytváří z nich zobrazovací moduly, může to rozumně existovat společně s řadičem. Ale to by měl být kód, který existuje pouze kvůli odpovídajícím pohledům. Pokud existuje pravidlo o dezinfekci dat na obchodní úrovni, mělo by to existovat na úrovni vaší domény/služby (s testovacími jednotkami).

10
Eric King

Termín „obchodní logika“ je často matoucí, protože lidé mají různé názory na to, co to znamená. Podle mého názoru pojem „obchodní logika“ zahrnuje dvě oblasti

  • Logika domény
  • Logika aplikace

Doménová logika je logika související s hlavní oblastí, se kterou se vaše firma týká, takže pokud píšete aplikaci pro účetní, pak daňová pravidla, účetní pravidla atd. Jsou součástí doménové logiky.

Logika aplikace je logika související se skutečností, že používáte počítačový program. Může se jednat například o export do CSV importu, průvodců atd. Mohou také obsahovat věci jako vytváření e-mailů se zapomenutým heslem.

Druh "obchodní logiky", který můžete umístit do vrstvy řadiče, je aplikační logika. Možná by tam neměla jít celá logika aplikace. Logiku domény byste však nikdy neměli umisťovat do vrstvy řadiče. To by samozřejmě mělo být ve vrstvě domény.

Mluvili jste o logice formátování nebo dezinfekce dat. Formátování musí být rozhodně logikou aplikace. Dezinfekce na druhé straně by mohla být logikou domény, pokud je dezinfekce dat založena na pravidlech domény. To záleží na kontextu.

10
Pete

Řadiče by měly být velmi logičtí pro logiku domény.

Řídící jednotky by měly delegovat úkoly, jako je načítání záznamu z úložiště dat pomocí abstrahované vrstvy služeb/úložiště a předávání dat zpět do úložiště dat stejnou (nebo související) službou. Pokud jde o mechaniku a jemnější spolupráci mezi těmito operacemi, obvykle patří někde jinému než ovladač.

Často se ocitám v přidávání malých metod sanace dat k mým kontrolérům, které ukládají data zpět do úložiště, a přestože je to efektivní řešení, nezapadá dobře do zamýšlené role kontroléru. V ideálním případě by vše, co bude modifikovat, ověřit nebo analyzovat váš model, mělo nastat velmi blízko - pokud ne uvnitř - samotného modelu. Pokud například potřebujete objekt modelu před uložením „vyčistit“, zvažte použití metody SanitizeInputs () na modelu nebo jako součást služby, která zpracovává ukládání modelu.

4
Nathan Taylor

Z pragmatického hlediska jsem zjistil, že buď skončíš s logikou v ovladači nebo s chováním regulátoru ve svém modelu, když se snažíte udělat něco, pro co není dobrý přístup vyhovující vzoru. Jistě, pokud píšete aplikaci, která za tím nemá velkou infrastrukturu.

Můžete jít obousměrně, ale obvykle se snažím přemýšlet, jestli se ten divný kousek pravděpodobně projeví ve více než jedné akci ovladače, pokud to jde v modelu. Pokud to není jasné, snažím se přemýšlet, zda je „na jednom místě“ více než na druhém. Pokud to neudělám, obvykle ho do modelu vložím jen proto, abych ho držel mimo ovladač (osobní preference pro menší řadiče a silnější datové objekty, YMMV)

Třetí možností by bylo odkazovat na užitkové položky jako na samostatnou třídu užitku, ale to je podle názoru mnoha také proti vzoru.

Také jen proto, že se přesně nedržíte vzoru, nemusíte nutně flirtovat s katastrofou. Pokud opravdu neočekáváte značné množství opakovaného použití kódu mimo tento projekt, staral bych se mnohem víc o to, aby byl projekt sám o sobě konzistentní (tj .: neplést, kam umístíte tyto bity, jakmile vyberete umístění) než přepsat, že z nějakého důvodu chce zachránit část středu projektu. Dokument/komentář kde a proč jste se odchýlili od společného vzoru a definujte očekávaný vzor pro tuto aplikaci.

MVC byla odchylka od zavedených vzorů sama o sobě v jednom bodě.

4
Bill

Stejně jako mnoho jiných zajímavých konceptů v programování je MVC výkonným vzorem, který přináší strukturu a zaměření na rodinu blízkých nebo podobných strategií k implementaci určitých scénářů.

Stejně jako mnoho jiných programových konceptů, MVC zjednodušuje realitu, zahodí malé detaily a poskytne hrubý model drátového modelu, který bude následovat. Stejně jako mnoho jiných zjednodušení reality to funguje tak, že přináší strukturu do chaosu, jak jej vidí lidská mysl.

Stejně jako mnoho jiných programovacích konceptů je MVS jen zjednodušením reality. Není to dokonalé a není to důkladné. Z tohoto důvodu není možné scénář reálného světa začlenit do příliš zjednodušeného modelu. Proto vyvstává mnoho otázek podobných této.

  • Kolik logiky by mělo jít do kontroléru?

  • Zda by pohled měl obsahovat nějakou podmíněnou logiku?

  • Zda by model měl obsahovat nějaké další údaje, které se přímo nenacházejí v podnikatelských subjektech?

To jsou všechny otázky zrozené ve snaze upravit kód tak, aby přesně a úplně odpovídal koncepční myšlence MVC.

Moje odpověď na vás se nesnaží. MVC poskytuje strukturu. Vytvořte svou aplikaci kolem tohoto základu, ale neočekávejte, že se dokonale hodí. Tam budou odchylky, je to normální. Jen je sledujte, abyste je udrželi pod kontrolou.

4
user8685