I agree more or less, I hate having my configuration data spread everywhere. I prefer to dedicate a name space to maintain/access configuration data. I usually split access to resources using bundles. A bundle can reflect anything you want in your design, including a controller...
This allows you to later change where you store and how you manage your configuration underneath, calls to the configuration are traceable in your code (conf/...) and you can easily stub it for testing purposes. Yes you need some discipline to avoid accessing it from everywhere (it could be tempting) but in general I refer to it at the top level and pass bits of the configuration data downward. Downward in your code you refer to semantics that have little to do with what the configuration data may represent as a whole. E.g. when trying to create a socket, you do not matter where the host/port came from in your configuration, you just need the values as args. It helps keeping your functions as pure a possible or at least with a clearly delimited side effect scope and still allows tests to be written. Attaining 100% purity is in my view a nice but rarely reachable objective. I would say that 80 to 90% is more realistic :) Luc P. > Am Dienstag, 10. September 2013 09:19:35 UTC+2 schrieb Alexandr Kurilin: > > > > > - Something in the middle where perhaps you agree to never directly > > reference the configs map from your models (again, thinking MVC here) > > and > > instead only ever access it from controllers, and pass the necessary > > options along down to the model functions. This way you can test both > > controllers and models in isolation in purity. > > > > > I'd do the following: for every layout of your application (persistence, > datamodel, web) define one or more vars that hold the configuration > specific for that layer. Testing a layer is easy and documentation of the > layer gives you the necessary information about the configuration vars. > > -billy. > > -- > -- > 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. > -- Softaddicts<lprefonta...@softaddicts.ca> sent by ibisMail from my ipad! -- -- 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.
