launchpad-dev team mailing list archive

[Guilherme Salgado <salgado@xxxxxxxxxxxxx>]

On Thu, 2010-08-26 at 16:44 +0100, Jonathan Lange wrote:
> On Thu, Aug 26, 2010 at 2:47 PM, Guilherme Salgado
> <salgado@xxxxxxxxxxxxx> wrote:
> ...
> > On Thu, 2010-08-26 at 08:52 +1000, Ian Booth wrote:
> > [...]
> >> What would I do? Well layered architectures I've worked with in the past
> >> include a persistence layer containing data access objects (DAOs). These
> >> are responsible for collaborating with the O/R mapping infrastructure to
> >> retrieve/save objects from the domain model and it's here where the O/R
> >> mapping logic is placed. For testing purposes, the DAOs can be stubbed
> >> out or an alternative method can be used, but the key point is that
> >> business domain objects are created for the various unit tests without
> >> the need for the database.
> ...
> >> What do others think? Are my thoughts sensible? Is the type of
> >
> > I like your suggestion. Here are some thoughts:
> >
> >  - ISTM that we could do this incrementally without disrupting anything,
> > so we don't need a coordinated effort to do it all at once
> 
> Really? I haven't thought much about it. How would you go about doing
> this incrementally?

By incrementally I meant one content class at a time, but I haven't
thought much about it either, so I may have missed something.

I was thinking it'd go something like this, for, say, EmailAddress:
  
  1. Create a DAO for it

  2. Move all ORM attributes and methods that just deal with DB to the
DAO

  3. Make the DAO methods return EmailAddress objects (using
DecoratedResultSet?) instead of raw DAOs as returned by storm.

  4. Make EmailAddress use that DAO through lazr.delegates so that
callsites have access to both the DAO and EmailAddress interfaces

  5. Change the EmailAddressSet utility to construct instances of
EmailAddress using the DAO instances (again, DecoratedResultSet?)
whenever necessary (i.e. when the utility uses the DAO directly to query
the DB).  Or maybe move the code that does that to the DAO, making it
return EmailAddress objects as well.

  6. Make sure only the DAO uses storm directly to query the DB for
email addresses, so that we don't expose DAO instances externally

  7. Also need to change all classes that have References to
EmailAddress because now they'll return DAOs and not instances of your
content class

And there are probably other things that I've missed, but this is
already a lot more than I was expecting.

-- 
Guilherme Salgado <https://launchpad.net/~salgado>

Attachment: signature.asc
Description: This is a digitally signed message part