Bien que j'aie trouvé de nombreux exemples de multilocation dans les applications Rails lorsque j'ai commencé à le faire, je n'en ai pas trouvé un qui me mette complètement à l'aise non plus. Mais j'ai enfin une solution qui me satisfait.
J'ai commencé avec le railscast 'multitenancy with scopes'
http://railscasts.com/episodes/388-multitenancy-with-scopes
a ensuite examiné la possibilité de faire fonctionner la multilocation avec des sous-domaines de conception à l'aide de ce guide :
https ://github.com/plataformatec/devise/wiki/How-To:--Isolate-users-to-log-into-a-single-subdomain
Mais je n'ai pas pris cela au pied de la lettre; J'ai plongé pour vraiment comprendre comment le design fonctionnait de cette façon.
Une fois tout cela en place, j'étais prêt pour le joyau multi-locataire :
https://github.com/wireframe/multitenant
Mais je ne me suis pas arrêté là. le gem multitenant nécessite que vous disiez Multitenant.with_tenant chaque fois que vous voulez que les choses soient correctement étendues, j'ai donc créé un TenantController qui ressemble à ceci :
around_filter :scope_current_tenant
def scope_current_tenant
begin
Firm.current = Firm.find_by_subdomain!(request.subdomain)
rescue
raise ActionController::RoutingError.new('Not Found')
end
Multitenant.with_tenant Firm.current do
yield
end
ensure
Firm.current = nil
end
end
puis tout contrôleur que je veux voir dans la portée du locataire hérite de TenantController plutôt que d'ApplicationController. De cette façon, je n'ai pas eu à me souvenir de quoi que ce soit dans les détails du contrôleur, ça "a juste fonctionné". la seule chose à laquelle les développeurs devaient penser était "est-ce un contrôleur qui gère les données des locataires ?"
Bien que cela dépende toujours du fait que les développeurs fassent certaines choses correctement (hériter du bon contrôleur, dire "acts_as_multitenant" dans le modèle, cela fonctionne très bien dans la pratique.
