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

Re: [agileDatabases] Data services

Expand Messages
  • Scott W. Ambler
    ... I wrote about this strategy in Agile Database Techniques and summarized it at
    Message 1 of 2 , Jul 1, 2005
    View Source
    • 0 Attachment
      At 04:31 PM 6/30/2005, Bryan wrote:

      >I have recently joined a project that wishes to encapsulate all data access
      >within "data services". A data service will contain one or more DAO's, which
      >will generally use Hibernate to map a transfer object model to tables. These
      >data services are intended to be topic based, and will be findable using a
      >service locater pattern.

      I wrote about this strategy in Agile Database Techniques and summarized it
      at
      http://www.agiledata.org/essays/implementationStrategies.html#StrategyServices
      if it helps.


      >This is an architecture I have not used before in the persistance layer.
      >Generally, I've taken an approach that simply makes DAO's reuseable across
      >business services, possibly with a DAO factory to manage construction and
      >common configurations. My first question is whether anybody has used a similar
      >data services approach and if anybody has any references that explain when and
      >why this data services architecture might be useful and how it compares to a
      >simple-minded "reuse the DAO's directly approach".

      This is a higher level level of encapsulation that DAOs, IMHO, assuming that:
      1. You use a services technology that is reusable on several
      platforms. For example, writing Java services around Java DAOs doesn't buy
      you much, writing Web Services around Java DAOs does.
      2. You can get the interface of the services right. For example, there
      wouldn't be much value writing four CRUD services for each DAO, there would
      be value in creating a SaveOrder() service which saves an XML structure
      representing an Order, Customer info, and Order Item info using the
      respective DAOs.


      >Second, I am wrestling with the question of how fine or coursed grained to
      >make
      >my data services, which effectively is a question of how to scope the
      >"topics".
      > This could range anywhere from having one service per DAO to one data
      > service
      >per database. Any advice or experience here would be appreciated.

      You need to understand the usage which you need to support (e.g. do some
      use case modeling, perhaps some user stories). If you just do data
      modeling you're pretty much guaranteed to get it wrong because it's not
      data that you need to model here, it's services.

      One way to identify services is overviewed at
      http://www.agilemodeling.com/artifacts/sequenceDiagram.htm#Figure1 . As
      you can see, it indicates the potential need for business services such as
      check to see if student exists, verify that a person is eligible to enroll,
      add applicant to database, and calculate enrollment fees. To support these
      services you would need to access the database. Whether you want to do
      that directly through DAOs, or through a layer of "pure data services",
      whatever that implies, is up to you. Arguably the first and third business
      service that I listed are mostly data services, at least on the surface.

      I would lean towards a one service uses multiple DAOs approach, with many
      services being written. But I really don't know anything about your
      environment so take that advice with a grain of salt.

      - Scott

      ====================================================
      Scott W. Ambler
      Senior Consultant, Ambysoft Inc.
      www.ambysoft.com/scottAmbler.html

      www.agiledata.org -:- www.agilemodeling.com -:- www.ambysoft.com -:-
      www.databaserefactoring.com -:- www.enterpriseunifiedprocess.com -:-
      www.ronin-intl.com
    Your message has been successfully submitted and would be delivered to recipients shortly.