r2 - 20 Feb 2007 - 12:48:19 - BobbyRulloYou are here: OSAF >  Journal Web  >  BobbyRulloNotes > ClientSideDashboardPlumbingTasks > AnemicVersusRich
Since we may have the opportunity to redo a lot of the plumbing work on the CosmoUI?, I'd like to revisit this topic.

Anemic Domain Model


  • Anemic is what we have now
  • model objects are really just data holders, with very little functionality in them.
  • For instance, items don't know how to save themselves
  • Collections aren't really collections, they're just metadata
  • advantages:
    • this is what we have. It works
    • relatively simple implementaion
  • disadvantages:
    • can be awkward to code in - you can't say "collection.getItems()" you have to say Service.getItems(collection.getUID())
    • you have to seperate structues in the code which maitain what belongs in what collection.

Rich Domain Model


  • objects have verbs and nouns, they "know" how to do stuff
    • event.save()
    • event.update()
    • event.isDirty() and so forth
  • collections would be...collections.
  • collection.getEvents(startDate, endDate)
  • advantages
    • coding can feel more natural
    • you don't have lots of stray objects all over the place, not "in" their collections
    • it could be easier this way to manage the layer between the service code and the ui code.
  • disadvantages
    • could be hairy as heck to implement (see next section)

Challenges of Implementing a Rich Domain Model


  • Right now we don't have the whole problem that the Chandler has with recurring events not "really" being items - things that are not really persisted (unless they are mods...) and all the confusion that brings
  • You'd have to somehow inject the DAO stuff into objects as they are created, and de-seriailized
  • When you get a bunch of items back from the server, how do you replace all the current instances that are hanging around the app with new ones?
  • ... ?

How I'm feeling about this right now


I'm feeling like it's a bit of a risk to go rich. Especially the whole thing of updating instances that are out there in the app. Of course we could still deal with this by making sure that all references to all objects are in some central repository and that if you get an updated version of the item from the server you just update the current version in the repository. Worried about peformance and backwards compatability though.

I still don't like the fact that our Collections aren't colletions - that is, they don't contain items, they are just metadata. Might be something we have to live with.

Edit | WYSIWYG | Attach | Printable | Raw View | Backlinks: Web, All Webs | History: r2 < r1 | More topic actions
 
Open Source Applications Foundation
Except where otherwise noted, this site and its content are licensed by OSAF under an Creative Commons License, Attribution Only 3.0.
See list of page contributors for attributions.