Object Models - decoupling data access - good examples ?

Discussion in 'Python' started by shearichard@gmail.com, Aug 5, 2012.

  1. Guest

    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.
    , Aug 5, 2012
    #1
    1. Advertising

  2. Roy Smith Guest

    In article <>,
    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?
    Roy Smith, Aug 5, 2012
    #2
    1. Advertising

  3. Guest


    >
    > 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.
    , Aug 5, 2012
    #3
  4. Roy Smith Guest

    In article <>,
    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.
    Roy Smith, Aug 5, 2012
    #4
  5. On Sat, 2012-08-04 at 20:26 -0700, 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.

    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v2.0.18 (GNU/Linux)

    iEYEABECAAYFAlAhEWkACgkQLRePpNle04N/dgCfSklM1oSbUXNuEy4qP2i4YZ00
    zNYAniMK5d6rTPLQ8wD5vbj53W0A/eUQ
    =8Zzb
    -----END PGP SIGNATURE-----
    Adam Tauno Williams, Aug 7, 2012
    #5
  6. Sells, Fred Guest

    Given that "the customer is always right": In the past I've dealt with thissituation 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.

    -----Original Message-----
    From: python-list-bounces+frsells= [mailto:python-list-bounces+frsells=] On Behalf Of
    Sent: Saturday, August 04, 2012 11:26 PM
    To:
    Subject: Re: Object Models - decoupling data access - good examples ?


    >
    > 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 assureyou what's in that 'bardb' is a pretty thin layer over the SQL and nothinglike the, pretty amazing, functionality of, for instance, SQLAlchemy.



    --
    http://mail.python.org/mailman/listinfo/python-list
    Sells, Fred, Aug 7, 2012
    #6
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. VisionSet

    Decoupling musing

    VisionSet, Nov 20, 2005, in forum: Java
    Replies:
    5
    Views:
    362
    Andrew McDonagh
    Nov 20, 2005
  2. vinjvinj
    Replies:
    15
    Views:
    564
    Jeremy Sanders
    Nov 10, 2005
  3. Jean-Paul Calderone
    Replies:
    0
    Views:
    425
    Jean-Paul Calderone
    Nov 7, 2005
  4. Replies:
    15
    Views:
    473
    Dennis Lee Bieber
    Jan 30, 2006
  5. David Heinemeier Hansson
    Replies:
    0
    Views:
    220
    David Heinemeier Hansson
    Dec 23, 2004
Loading...

Share This Page