Korny mentioned java.jdbc and I figured that was a good in to talk about how we use it at World Singles. Even with the old API we used a function in a specific namespace that returned the data source (in fact it returned a pooled data source, using c3p0). Behind the scenes, we actually use an atom to provide a cached, singleton instance. with-redefs allows us to mock that for testing, if needed :)
I haven't missed DI at all since moving to Clojure - after decades of OO - and I still use it in the non-Clojure, OO code that could be considered our "legacy" system that wraps our Clojure code. Clojure makes me think about my dependencies and organize them in a very clean top-to-bottom tree, with very clear divisions between subsystems. In the OO world, DI makes you sloppy... You can have circular dependencies. You can easily add whatever dependencies you need. You don't have to think about it, you can work around problems that crop up. Does that help Colin? Sean On Fri, May 10, 2013 at 4:04 AM, 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. > > -- Sean A Corfield -- (904) 302-SEAN An Architect's View -- http://corfield.org/ World Singles, LLC. -- http://worldsingles.com/ "Perfection is the enemy of the good." -- Gustave Flaubert, French realist novelist (1821-1880) -- -- 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.
