Thanks Jason, I will take a look. On Sunday, 12 May 2013 01:27:11 UTC+1, Jason Wolfe wrote: > > 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.
