Object Models - decoupling data access - good examples ?

[shear...@gmail.com]

I'm interested in best practice approaches to : decoupling data access code from application code; and translations between database structures and domain objects.

For some time I've done database access by in a particular way and while I think it's OK it's not very pythonic so I'd be interested in hearing of other approaches - even better if there are open source examples whose code might be read.

I should say I'm talking relational database here and, for various reasons, ORMs are not involved.

So this is what I do (in a one class project call 'bar') in order to allow objects of type foo to be fetched/inserted/updated


bar/foo.py
bar/bardb/bardbConnection.py
bar/bardb/BusinessLogic/fooManager.py
bar/bardb/BusinessObject/foo.py
bar/bardb/DataAccess/fooDB.py

And this is what they actually do :


bar/foo.py
The class as the outside world knows it

bar/bardb/bardbConnection.py
Manages database connection

bar/bardb/BusinessLogic/fooManager.py
Exposes methods used by bar/foo.py such as 'save'/'update' etc and implements necessary validation etc

bar/bardb/BusinessObject/foo.py
A collection of getters/setters which does any translation between types necessary on the way to/from the rdbms

bar/bardb/DataAccess/fooDB.py
Implements the actual SQL necessary for the relevant interactions with the database

As I say this works OK for me but I'd be interested to hear of what others do.

Thanks

Richard.

[Roy Smith]

In article <ebb88ade-7598-46b1...@googlegroups.com>,

shear...@gmail.com wrote:

> I should say I'm talking relational database here and, for various reasons,
> ORMs are not involved.

Just out of curiosity, why do you eschew ORMs?

On the other hand, you really haven't. All you've done is rolled your
own. So, the real question is, why do you want to roll your own ORM
instead of using some existing one?

[shear...@gmail.com]

>
> Just out of curiosity, why do you eschew ORMs?
>

Good question !

I'm not anti-ORM (in fact in many circs I'm quite pro-ORM) but for some time I've been working with a client who doesn't want ORMs used (they do have quite good reasons for this although probably not as good as they think).

I was interested to know, given that was the case, how you might - in Python, go about structuring an app which didn't use an ORM but which did use a RDBMS fairly intensively.

I take your point about having "rolled my own ORM" - lol - but I can assure you what's in that 'bardb' is a pretty thin layer over the SQL and nothing like the, pretty amazing, functionality of, for instance, SQLAlchemy.

[Roy Smith]

In article <bf551938-0b08-46d5...@googlegroups.com>,

shear...@gmail.com wrote:

> > Just out of curiosity, why do you eschew ORMs?
> >
> Good question !
>
> I'm not anti-ORM (in fact in many circs I'm quite pro-ORM) but for some time
> I've been working with a client who doesn't want ORMs used (they do have
> quite good reasons for this although probably not as good as they think).

OK, I'll re-ask the question. What are the reasons?

> I take your point about having "rolled my own ORM" - lol - but I can assure
> you what's in that 'bardb' is a pretty thin layer over the SQL and nothing
> like the, pretty amazing, functionality of, for instance, SQLAlchemy.

So, you're opposed to ORMs in general because you find SQLAlchemy too
heavyweight. I don't blame you; every time I look at SQLAlchemy, I go
screaming in the other direction. But, there are other ORMs. See, for
example, http://lmgtfy.com/?q=python+orm.

[Adam Tauno Williams]

On Sat, 2012-08-04 at 20:26 -0700, shear...@gmail.com wrote:
> >
> > Just out of curiosity, why do you eschew ORMs?
> Good question !
> I'm not anti-ORM (in fact in many circs I'm quite pro-ORM) but for
> some time I've been working with a client who doesn't want ORMs used
> (they do have quite good reasons for this although probably not as
> good as they think).

So call the ORM something else.

> I was interested to know, given that was the case, how you might - in
> Python, go about structuring an app which didn't use an ORM but which
> did use a RDBMS fairly intensively.

You'd reinvent the ORM calling it something else - because an ORM is
what you are describing.

This is just a case of those-who-will-not-use-are-doomed-to-recreate.

> I take your point about having "rolled my own ORM" - lol - but I can
> assure you what's in that 'bardb' is a pretty thin layer over the SQL
> and nothing like the, pretty amazing, functionality of, for instance,
> >SQLAlchemy.

This implies that SQLAlchemy is 'fat'. I don't see any evidence of
that. It is comprehensive so when you encounter something you can be
confident it is up to the challange.

[Sells, Fred]

Given that "the customer is always right": In the past I've dealt with this situation by creating one or more "query" classes and one or more edit classes. I found it easier to separate these.

I would then create basic methods like EditStaff.add_empooyee(**kwargs) inside of which I would drop into (in my case) MySQLdb. In retrospect, I'm not sure that the generick use of **kwargs was a good solution in that it masked what I was passing in, requiring me to go back to the calling code when debugging. OTOH it allowed me to be pretting generic by using
Sql = sql_template % kwargs

On the query side. I would convert the returned list of dictionaries to a list of objects using something like

Class DBrecord:
Def __init__(self, **kwargs):
Self.__dict__.update(kwargs)

So that I did not have to use the record['fieldname'] syntax but could use record.fieldname.

I would describe myself as more of a survivalist programmer, lacking some of the sophisticated techniques of others on the mailing list so take that into account.

Fred.

--
http://mail.python.org/mailman/listinfo/python-list