Tento prístup k modelu regulátora s nízkym obsahom tuku zachádza priďaleko
Bojím sa, že by som mohla byť lenivá.
Vyvinuli sme aplikáciu rubínovej dráhy, ktorá obsahuje asi 8 modelov pre dva typy používateľov: lekárov a pacientov. Väčšina logiky je vo vnútri modelov, ktoré umožňujú, aby pôsobenie môjho ovládača bolo veľmi krátke a výstižné. Okrem toho je testovanie celkom jednoduché.
Momentálne vidím minimálne dva ovládacie prvky a testy, ktoré napíšem, ma priviedli k presvedčeniu, že väčšinu mojich funkcií, s ktorými sa používatelia stretávajú, môžu tieto dva ovládače spravovať. Iste, môžem to rozdeliť na citlivejšie oddelenia - ako sú testy pre pacienta-kontrolóra, lekára-kontrolóra, pacienta-kontrolného lieku, pacienta-laboratórne-výsledky-kontrolného, a tak ďalej. Ale zdá sa mi, že jedinou výhodou tu je diskrétnejšia organizácia.
Na otázku, okrem oddeľovania, aké sú dôvody nepoužívania čo najmenšieho počtu ovládačov, je treba zabaliť do množstva akcií [nevýhoda], ale akcie ponechať tenké [výhoda]? Alebo dajte to do extrému: prečo nie s MVC, máte veľa tučných modelov a slabú kontrolórku [aj keď dlhú], a nie kontrolóra pacienta/model/názory + testy pre každého, kontrolóra lekára/modelku/názory + testy pre každú atď?
3 odpovede
Existuje organizácia, pretože všetko, čo robí jeden kontrolór, je možné, bude ťažšie pochopiť a zmeniť. Namiesto toho, aby ste mohli otvoriť súbor v editore a okamžite nájsť hľadanú akciu, posuňte sa v zozname a nájdite to, čo hľadáte.
To vedie aj k modelu Predmet Boha v ktorom sa všetko deje vo vnútri jedného objektu, ktorý je za všetko zodpovedný a každý, kto pracuje na projekte, zmení ten istý objekt, čo vedie k starému peklu spojenia.
A na samotných Rails je tu RESTfulness rámu. Rails prijíma myšlienku byť RESTful a jedným z pilierov tejto myšlienky sú zdroje a dajú sa ľahko usporiadať iba v samostatných riadiacich jednotkách. Ak sa pokúsite umiestniť dva rôzne zdroje na ten istý radič, pravdepodobne skončíte bláznivými trasami alebo šialeným logickým radičom, aby ste zistili, ktorý model je reprezentovaný.
Ak si myslíte, že vaše ovládače majú veľa opakovaných kódov, môžete ich odstrániť pomocou niekoľkých metaprogramov alebo konvencií, ale je ešte lepšie ich oddeliť, nielen kvôli organizácii, ale aj kvôli zjednodušeniu budúcej údržby.
Na túto otázku je nemožné odpovedať. Kontrolóri nie sú o obchodnej logike, o trasách a interakciách a víziách používateľov. Máte toľko kontrolórov a akcií, koľko má zmysel pre vaše spojenia a názory.!
Ak je vaša obchodná logika obsiahnutá vo vašich modeloch, je to dosť jednoduché. Hlavnou ťažkosťou s logikou v radičoch je, že nemôžete znovu použiť logiku.
Už niet čo povedať. Je len na vás, aby ste urobili napríklad to, čo má zmysel vo vašej aplikácii. máte radič na hľadanie vecí, namiesto toho, aby ste pridali akciu hľadania k svojim existujúcim radičom, nie je v skutočnosti nič iné ako oddelenie a jasnosť
Ak existuje veľa bežnej logiky radiča, odporúčame vám ho extrahovať do pluginu alebo ako ho môžete podľa potreby zmiešať. Alebo by ovládacie prvky mohli dediť zo spoločného základného radiča (rovnako ako všetky radiče dedia predvolene z ApplicationController, skôr ako ActionController: Base).
Poradil by som vám, aby ste nemali obrovský ovládač; radič by mal riadiť množinu akcií, ktoré sa týkajú jedného typu zdroja (alebo najbližšieho možného analógu). Táto myšlienka je ešte silnejšia, ak sa pokúsite vytvoriť návrh RESTful, v ktorom každý radič zvyčajne nemá nič iné ako sedem základných akcií (indexovanie, prezentácia, vytváranie, úprava, aktualizácia, ničenie).
Takže ak chcete mať adresy URL ako/pacienti/52394802/lab_results, myslím si, že je rozumné mať LabResultsController. Ak sú tieto ovládacie prvky jednoduché, úžasné. Verím, že ich existencia je stále oprávnená. To vám nezabráni v pokuse získať váš DRY kód; skôr by som sa pokúsil zneužiť bežnú funkčnosť inak.