On 05/12/2012 14:13, Jonathan Hartley wrote:
I guess you still need to provide an abstraction for these features,
even if only one backend supports the abstraction.
What I'm reading suggests that if, for example, your app needs to use a
text indexing service, then that's an external system and your
application core should define an API which it will use to talk to it.
Isn't this just the API provided by whatever python library you choose
to use?
So you still get to use features like this, but you are obliged to put
an API layer (and possible inversion of control) between them, rather
than making the call directly from within your business logic.
What's the actual benefit of this other than an additional layer of
complexity and one more call in the stack?
Similarly, if your business logic needs a small number of particular
relational-type queries, then perhaps those queries should be the API
defined by your core for talking to persistence.
This would appear to kill the ad hoc querying that makes relational
databases so powerful. sqlalchemy is about as much of an abstraction as
I'd ever want...
If your app needs many
such queries, or general-purpose relational querying support, then
perhaps you can create an API which supports general purpose querying
such as the 'repository' pattern.
Again, what's the actual benefit of this other than the theoretical
ability to switch implementations, which you'll likely never use?
Chris
--
Simplistix - Content Management, Batch Processing & Python Consulting
- http://www.simplistix.co.uk
_______________________________________________
python-uk mailing list
python-uk@python.org
http://mail.python.org/mailman/listinfo/python-uk
