I'm a fan of a standard factory class pumping out simple objects representing the
data. This way you can write the factory with
your SQL optimized for the database in question, and have a standard API for
interfacing with the system. Pretty much what
middlekit is going for, but with Python and the ability to make classe attributes on
the fly it is pretty easy to do a simple
factory pattern.
I have a factory class with simple methods such as
getUser(userName) - pulls a user from the db
requestUser(Requestor, userName) -pulls userName from the db, based on the permissions
of Requestor.
All the methods return a 'user' object - which right now is pretty much
class user:
pass
in my factory only getUser actually goes to teh db and there is a sigle SQL statement
(based on a PostGres VIEW) that pulls in the
data object.
Then I just create a new instance of the class and add up attributes as needed
So if I decide that I need the companyID field as well as the company Name I just edit
the SQL statement and add a line something
like:
user.companyID = resultSet.companyID
since user is an object adding fields should not affect the rest of app. Now I access
these variables with a simple user.companyID
but with pythons object overloading I can even turn that call into a method at a later
date.
I really like the idea of MiddleKit, as well as other DB-code mapping strategies, but
they have to jump through a lot of hoops to
avoid what can be done in a relatively simple SQL command. My UserManager done in the
Java/Enhydra/DODS object mapper creates a
company object and then embeds that into the user object. I don't necessary need that
since my app treats the user as a discrete
object, in my code I just want a user object with a company field.
I don't usually care about caching, since I can cache content in Chetaha and
user/login info in a session. Most other content has
to roundtrip to the DB server anyway.
Just my $0.02
Thanks,
-Aaron
----- Original Message -----
From: "Ian Bicking" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Wednesday, October 17, 2001 10:36 PM
Subject: Re: [Webware-devel] MiddleKit thoughts
> Ian Bicking <[EMAIL PROTECTED]> wrote:
> > Anyway, that's where I am myself. There's other similar things to MK,
> > but most of them are lame dictionary interfaces (which capture the
> > easy 90% of the problem, but just make the other 10% of SQL queries
> > more awkward). I've looked at PyDO a little myself (it's part of
> > SkunkWeb), but haven't come to any opinion. The author talks about
> > some of these issues more or less in the intro to PyDO.
>
> I should ammend that and say that I don't actually think every
> dictionary access wrapper is "lame"... they deal well with a certain
> class of problems, usually where a database is treated like a fancy
> flat-file data store. A lot of problems only call for such a data
> store.
>
> But I have yet to see the system that lets you express a left join in
> any reasonable way. Honestly, I'm not even sure what it would mean to
> do a left join in MK or a similar product -- they rely on doing the
> queries mostly in Python, in an imperative fashion as opposed to SQL's
> declarative fashion. But I think SQL exists for a reason, and I just
> wish there was a way to mirror that functionality in Python. I want
> macros like in Lisp.
>
> I'm thinking of decompiling compiled Python functions into SQL :) In a
> way that's what SQLBuilder does -- but that's only a peripheral part
> of what I'm thinking of (and, I would expect, it's usable in MK or
> anything else that allows arbitrary clauses).
>
> Ian
>
> _______________________________________________
> Webware-devel mailing list
> [EMAIL PROTECTED]
> https://lists.sourceforge.net/lists/listinfo/webware-devel
_______________________________________________
Webware-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/webware-devel
