It's interesting to note that clojure.java.jdbc used to use our first option - they had a dynamically bound var *db* that you assigned using the (with-connection) macro.
As of version 0.0.3 this has been deprecated in favour of something like your second option - now you pass an explicit db parameter to each function, where 'db' can be a db connection specification, or an explicit connection already created from a with-transaction macro, or a number of other alternatives. It's worth having a look through the source: https://github.com/clojure/java.jdbc/blob/165c9d2c3151a244e5a323e817edba970f6bfbb5/src/main/clojure/clojure/java/jdbc.clj#L139 - Kornt On 10 May 2013 21:04, Colin Yates <colin.ya...@gmail.com> 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. > > > -- Kornelis Sietsma korny at my surname dot com http://korny.info .fnord { display: none !important; } -- -- 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.
