On Thu, Feb 19, 2015 at 5:59 AM, Oliver Berger <[email protected]> wrote: > What would be the difference except a more or less unified API to retrieve > the services? > May be I am missing the point....
My apps tend to have more factories than utilities, and they need to share things like database connections across them. Even the database connection is a factory. pyramid_services caches the result objects on the request so that they are only created once per request and shared so that database connection is only created once and then fed into each factory that needs it. The demo in the docs illustrates this happening. So to address your comments I'd say that first, your examples are basically all I'm doing under the hood aside from caching so don't stop if it works for you! Most people I've encountered don't know anything about multi-adapters though and don't want to. The four advantages I'd lay out are 1) a more unified API 2) a more strict coupling of services to the request lifecycle 3) all wiring/dependencies between services are setup at config time instead of in your views 4) and building off of that abstracted wiring, there's less zopey things going on in views allowing you to just focus on using the services as they were configured. -- You received this message because you are subscribed to the Google Groups "pylons-discuss" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/pylons-discuss. For more options, visit https://groups.google.com/d/optout.
