Loading ...
Sorry, an error occurred while loading the content.

Re: [XP] Architectural decision on Domain Objects

Expand Messages
  • Paolo Bizzarri
    ... Hi William. Thank you for your reply. And, yes, it has helped. It s also worth studying some other systems like Hibernate or Ruby on ... Thank you for the
    Message 1 of 9 , May 13 10:58 PM
    • 0 Attachment
      On 5/10/06, William Pietri <william@...> wrote:
      >
      > Hi, Paolo. I'm a little handicapped by your lack of specific questions
      > or particular problems. I'll try giving you another general opinion, and
      > perhaps that will help. If not, feel free to write back with more
      > specifics.



      Hi William. Thank you for your reply. And, yes, it has helped.



      It's also worth studying some other systems like Hibernate or Ruby on
      > Rails, plus of course Zope's approach. Although you can't use the code,
      > you can use the patterns, and you can use their strong points as goals
      > for your own work.



      Thank you for the advice. I believe this could be a good way of trying to
      learn some new way of doing things. As far as I understand, I believe Ruby
      will be more in tune with our current experience.


      It's also worth really learning test-driven development, where you
      > develop in a tight loop: write a little test, write just enough
      > production code to make it pass, and then refactor to make it clear. It
      > seems like it shouldn't relate to your architectural issues, but by
      > starting with the tests you look at your objects from the outside. That
      > broader perspective makes the architecture more visible.


      As a matter of fact, we do develop using TDD. Most of my questions come
      directly from being difficult to test our code, both old and new. In some
      areas testing is simpler, because we have developed some good approach to
      problems. In others, we have difficulties.


      Bringing this back to your original post, you asked:
      >
      > > who has to be in charge of the persistance ? Namely, the client code
      > > could be:
      > >
      > > folder.add(document)
      > > folder.update()
      > >
      > > or
      > >
      > > folder.add(document)
      > > forder_mapper.update(folder)
      > >
      > > Or we could embed the whole thing inside the add method of the folder
      > > object.
      >
      > When writing tests, I would certainly find the middle one a problem. Why
      > should I create a folder_mapper every time I'm working with a folder?
      > And what if I'm working with three or four kinds of domain object at
      > once? So that's out.
      >
      > The first one would offend me while refactoring. Why should I have all
      > of these duplicated update() calls every time I touch an object? It
      > would also probably come up while testing; I'd forget the necessary
      > update() call and break a test.
      >
      > So it sounds like the third one is the best approach. Then the question
      > becomes how best to hide the plumbing. There's an area where I'd look at
      > other O/R frameworks and steal, steal, steal. Complete O/R frameworks
      > are, I'm sure, fiendishly complicated. But simple ones are pretty easy
      > to write.



      I agree. I was trying to understand how to divide code among the client
      code, the code inside domain objects and the mapper (I have called mapper,
      but really it is more a finder/gateway towards our database structure).

      Now I understand my problem is how to deal with persistence, and who should
      have this responsibility.

      Hoping that helps,


      It helps. I think I have found a good criteria for moving code aroud, and
      dividing responibilities:

      - clients should simply get objects through finders, and performs
      operations of them
      -> a_folder = self.getFolderFinder().findByYearAndNumber(year=year, number
      = number)
      -> a_folder.setTitle('new title')

      - finders should retrieve the domain object, and register in a per
      transaction cache, so that we know which object we are manipulating

      -> domain objects should simply update themselves, and eventually interact
      with other finders in other to respond to methods

      -> the persistence manager should be called, for now explicitely, in order
      to make persisted the objects we have modified.

      Thanks again.

      Ciao

      Paolo


      [Non-text portions of this message have been removed]
    Your message has been successfully submitted and would be delivered to recipients shortly.