Diferite modele din aplicația dvs. Rails vor împărtăși adesea un set de preocupări transversale. În Basecamp, avem aproape patruzeci de astfel de preocupări cu nume precum Trashable, Searchable, Visible, Movable, Taggable.

îngrijorări

Aceste preocupări încapsulează atât accesul la date, cât și logica domeniului despre o anumită porțiune de responsabilitate. Iată o versiune simplificată a problemei etichetabile:

Această preocupare poate fi apoi amestecată în toate modelele care pot fi etichetate și veți avea un singur loc în care să actualizați logica și să argumentați.

Iată o preocupare similară în care tot ceea ce adăugăm este o metodă cu o singură clasă:

Preocupările sunt, de asemenea, o modalitate utilă de a extrage o felie de model care nu pare a face parte din esența sa (ceea ce este și nu este în esența unui model este o linie fuzzy și o discuție mai lungă) fără a merge complet plictisitoare. Principiul și riscul de a vă bloca inventarul de obiecte.

Iată o preocupare Dropboxed pe care o amestecăm doar în modelul Persoană, care ne permite să redirecționăm ulterior e-mailurile primite pentru a fi de la persoana potrivită:

Acum aceasta nu este cu siguranță singura modalitate de a tăia modele dolofane. Din motive de îngrijorare vizibilă, puteți avea Viewer.visible (current_account.posts, to: current_user) și încapsulați interogarea într-un obiect autonom. Pentru Dropboxed, ai putea avea o clasă autonomă Dropbox.

Dar consider că îngrijorările sunt adesea doar cantitatea potrivită de abstractizare și că deseori duc la un API mai prietenos. Prefer cu mult current_account.posts.visible_to (current_user) decât implicarea unui al treilea obiect de interogare. Și, bineînțeles, lucruri precum Taggable care trebuie să adauge asociații la obiectul țintă sunt greu de realizat în alt mod.

Este adevărat că acest lucru va duce la o proliferare de metode pe unele obiecte, dar asta nu m-a deranjat niciodată. Îmi pasă de modul în care interacționez cu baza mea de cod prin sursă. Această problemă se întâmplă să amestece totul într-un model mare sub capotă este irelevantă pentru înțelegerea modelului de domeniu.

De ani de zile folosim această noțiune de extragere a preocupărilor din modelele dolofane în toate aplicațiile de la 37signals. A avut ca rezultat un model de domeniu simplu și ușor de înțeles fără ceremonia inutilă. Modelul de domeniu Basecamp Classic are acum peste 8 ani și continuă să fie puternic cu utilizarea preocupărilor.

Această abordare a divizării logicii domeniului în preocupări este similară în unele moduri cu noțiunea DCI de roluri. Nu are acrobatie mixtă în timpul rulării și nici nu are prescripția „modelele tale vor fi complet lipsite de logică”, dar în afară de asta, va avea adesea ca rezultat o logică similară extrasă folosind nume similare.

În Rails 4, vom invita programatorii să utilizeze preocupări cu aplicațiile implicite/modelele/preocupările și aplicațiile/controlorii/preocupările care fac parte automat din calea de încărcare. Împreună cu învelișul ActiveSupport: Concern, este suficient suport pentru ca acest mecanism de factoring ușor să strălucească. Dar puteți începe să utilizați această abordare cu orice aplicație Rails astăzi.