On Tue, Feb 17, 2015 at 12:34 AM, Michael Merickel <[email protected]> wrote:
> Hey everyone,
>
> I've been using some patterns within Pyramid for a while to create
> service layers in my web apps. They allow me to keep all database
> connections and queries and any other business logic out of my views,
> and even off of the request object. I've packaged these helpers into a
> small library named pyramid_services.
>
> The library boils down to basically 2 methods.
> `config.register_service_factory()` and `request.find_service()` and
> it can be used with zope interfaces to lookup objects, or with simple
> strings as well.
>
> https://pypi.python.org/pypi/pyramid_services
> https://github.com/mmerickel/pyramid_services

I like having a standard way to do this, and I haven't been entirely
satisfied with other ways to manage things like Redis connections and
login code, and making them request attributes. But if the objects
aren't going to change for the lifetime of the application and are
thread-safe and you don't need an interface, what's the advantage over
putting them in settings or as a registry attribute on startup? It
seems like that's a lot of unnecessary overhead and potential points
of failure.

And how would you set up a request in a unit test, if you're just
calling a view method and not instantiating an entire app?

-- 
Mike Orr <[email protected]>

-- 
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.

Reply via email to