Az alacsony zsírtartalmú kontroller modellnek ez a megközelítése túl messzire megy
Félek, hogy lusta lehetek.
Fejlesztettünk egy rubin sín alkalmazást, amely körülbelül 8 modellt tartalmaz kétféle felhasználó számára: orvosok és betegek számára. A legtöbb logika azon modelleken belül található, amelyek lehetővé teszik, hogy a vezérlőm nagyon rövid és tömör legyen. Ezenkívül meglehetősen egyszerűvé teszi a tesztelést.
Jelenleg legalább két vezérlőt látok, és az általam írt tesztek arra engednek következtetni, hogy a felhasználók által tapasztalt legtöbb funkciómat ez a két vezérlő képes kezelni. Persze, ezt érzékenyebb részekre bonthatom - például a beteg-kontroller, az orvos-kontroller, a beteg-kontroller gyógyszer, a beteg-labor-eredmény-kontroller tesztjeire stb. De úgy tűnik számomra, hogy az egyetlen előny a diszkrétebb szervezés.
A kérdésre, a szétválasztáson kívül, mi az oka annak, hogy a lehető legkevesebb vezérlőt nem használjuk, csomagoljuk őket sok művelettel [hátrány], de a műveleteket vékonyan tartsuk [előny]? Vagy. vigye végletig: miért nem az MVC-vel, sok kövér modell van és gyenge kontroller [bár hosszú], nem pedig beteg kontroller/modell/vélemények + tesztek mindegyikhez, orvos kontroller/modell/vélemények + tesztek mindegyikhez stb?
3 válasz
Van egy szervezet, mert minden lehetséges, amit egyetlen vezérlő végez, nehezebb megérteni és megváltoztatni. Ahelyett, hogy megnyithatna egy fájlt a szerkesztőben, és azonnal megtalálná a keresett műveletet, görgessen a fájlra, hogy megtalálja azt, amit keres.
Ez vezet a modellhez is Isten tárgya amelyben minden egyetlen objektumon belül történik, amely mindenért felelős, és mindenki, aki a projekten dolgozik, ugyanazt az objektumot fogja megváltoztatni, ami egy régi pokolba vezet az egyesüléshez.
És magában a Rails-ben ott van a keret RESTful-jellege. A Rails átfogja a RESTful gondolatát, és ennek az ötletnek az egyik pillére az erőforrások, és egyszerűen csak külön vezérlőkbe szervezhetők. Ha megpróbál két különböző erőforrást elhelyezni ugyanazon a vezérlőn, akkor valószínűleg őrült útvonalak vagy őrült logikai vezérlő végzi, hogy megtudja, melyik modell képviselteti magát.
Ha úgy gondolja, hogy az illesztőprogramok sok ismételt kóddal rendelkeznek, néhány metaprogram vagy egyezmény segítségével eltávolíthatja őket, de még jobb, ha elkülöníti őket, nemcsak a szervezés, hanem a jövőbeni karbantartás egyszerűsítése érdekében is.
Ezt lehetetlen megválaszolni. A vezérlők az útvonalakról és a felhasználói interakciókról és elképzelésekről szólnak, és nem üzleti logikáról. Annyi vezérlője és művelete van, amennyire van értelme kapcsolataival és véleményével.!
Ha üzleti logikája megegyezik a modelljeivel, akkor ez elég egyszerű. A vezérlők logikájának fő nehézsége az, hogy nem használhatja újra a logikát.
Nincs más mondanivaló. Csak rajtad múlik, hogy mit tesz értelme például az alkalmazásodnak. van egy keresésvezérlője a dolgok keresésére, ahelyett, hogy keresési műveletet adna hozzá a meglévő vezérlőihez, valójában nem másról van szó, mint az elkülönítésről és az egyértelműségről
Ha sok a közös vezérlő logika, javasoljuk, hogy bontsa ki egy pluginba, vagy hogyan keverje össze, ha szükséges. Vagy a vezérlők örökölhetnek egy közös alapvezérlőtől (ahogy az összes vezérlő alapértelmezés szerint az ApplicationController-től örököl, nem pedig az ActionController: Base).
Azt tanácsolom, hogy ne legyen óriási vezérlője; egy vezérlőnek kezelnie kell az egyetlen erőforrástípushoz (vagy a lehető legközelebb eső analóghoz) kapcsolódó műveletek halmazát. Ez az ötlet még erősebb, ha megpróbál létrehozni egy RESTful tervet, amelyben minden vezérlőnek általában nincs más, mint a hét alapvető művelet (indexelés, bemutatás, létrehozás, szerkesztés, frissítés, megsemmisítés).
Tehát, ha olyan URL-eket szeretne megkapni, mint a/betegek/52394802/lab_results, akkor úgy gondolom, hogy érzékeny a LabResultsController használata. Ha ezek az ellenőrzések egyszerűek, csodálatosak. Úgy gondolom, hogy létezésük még mindig indokolt. Ez nem fogja megakadályozni abban, hogy megpróbálja megszerezni a DRY kódot; inkább megpróbálnám másként visszaélni a közös funkcionalitással.