Hi Colin, This is one of the reasons we created graph:
https://github.com/prismatic/plumbing which is a general declarative mechanism for describing complex function compositions. There's not an awesome public example yet, but we use Graph at Prismatic to build our production services, where each node builds a single component of a service, based on other named other components and parameters. This ends up looking somewhat similar to dependency injection, although the details are rather different. Basically you get the advantages of your second option (no global state), but hopefully without the 'yuck'. If you're interested, I'm happy to answer questions here or on the plumbing mailing list: https://groups.google.com/forum/#!forum/prismatic-plumbing Cheers, Jason On Friday, May 10, 2013 4:04:20 AM UTC-7, Colin Yates wrote: > > (newbie, getting better each day!) > > I assume we all know DI. Through the use of a central registry I can > register a service (a bean in a Spring bean factory for example). I also > define consumers of that service in the same registry passing in the > configured *instance* of that service. > > In Clojure I have a service (i.e. a datasource) defined in its own > namespace. What is idiomatic Clojure?: > > 1) to use (defonce *data-source*...) so that every body who requires that > ns gets the same instance? > 2) to provide a 'get-ds' accessor which returns a new instance and rely > on passing that service along to every function that needs it? > 3) some other way I don't know about > > Option 1 seems to be less-typing, but now functions aren't pure - they > depend upon state defined elsewhere. I can change the binding through > 'with-XYZ' type functions, but that isn't solving the non-explicit > dependency between the function and the state. > > Option 2 means functions are still pure, but how do you prevent huge lists > of services - i.e. if func-a calls func-b which calls func-c and func-c > needs service-a then func-a and func-b need to access service-a. Yuck. It > also means the main entry point to my application needs to assemble all of > these services up in one go. > > To be more explicit - DI containers provide a graphs of logic coupled with > state - the state being the instances of the collaborators (i.e. "I will > have ConsumerA with an instance of SimpleServiceA please"). Clojure has > very strong opinions about how to manage state. > > How does the Clojure community handle this use case of separating out the > definition of a service, the configuration of that service and providing > that service as a collaborator to a consumer? > > Thanks a bunch. > > Col > -- -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
