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

Re: [XP] Is Mocking useful in 3 layer arch?

Expand Messages
  • William Pietri
    Hi, Muhammad. Thanks for dropping by; your questions are good ones. ... If you want to stick with your current architectural patterns, the Hibernate unit tests
    Message 1 of 5 , Jul 3, 2006
      Hi, Muhammad. Thanks for dropping by; your questions are good ones.

      Muhammad Ichsan wrote:
      > A have dao (data access object) implementation with hibernate. In
      > service layer the dao passes the domain object to be processed.
      > Sometimes service methods try to get properties of the domain object
      > managed by the hibernate. In some case hibernate may throw exception
      > because session has been closed.
      >
      > In short, I just want to make sure the behaviour of the hibernate
      > object in data layer not throw any exception. This is what I call
      > success in service layer.
      >
      > Is this problem can be devided into two subproblems:
      > - test the service layer no matter the daos are.
      > - test the behaviour of hibernate object.
      >
      > I think this is gonna be complecated test. I guess.

      If you want to stick with your current architectural patterns, the
      Hibernate unit tests will have to exercise the object in the same way
      the higher layers will to make sure no exceptions will be thrown.

      However, I'd recommend that you change your approach in a few ways.

      First see if you can keep the Hibernate session open. If we're talking a
      web application here, this means closing the session after you transmit
      the response. Then there's no risk of unexpected exceptions, and keeping
      the session open for a few extra milliseconds is a small price to pay.

      It also sounds like you are implementing a 3-tier architecture in
      layers. In my experience, that often leads to Martin Fowler's "Anemic
      Domain Model" anti-pattern, and it's hugely inefficient. In a multi-tier
      architecture you're obliged to copy your data repeatedly because you're
      crossing JVM boundaries all the time. But if you just turn the tiers
      into layers, you end up with a huge amount of unnecessary copying.

      Instead, consider eliminating the DAO layer, using Hibernate to map your
      domain objects directly to the database, and moving a lot of the service
      layer code into the domain objects themselves. You'll end up with a much
      cleaner model, one that will be easier to test.

      Third, rather than separating things out via mocks, I'd suggest you test
      things together when speed allows it. One way to do that with Hibernate
      is to use an in-RAM database like Hypersonic for most of your tests.
      Another is to make Hibernate itself pluggable: make a thin persistence
      interface, then make a Hibernate implementation and one that just stores
      your "persistent" objects in HashMaps for the duration of the tests.
      Either approach is fast, and either approach lets you easily try all of
      your unit tests against particular databases if you'd like to. Of
      course, you'll still need unit tests for the Hibernate mappings, and I
      prefer to do those against a real database.



      Hoping that helps,

      William
    • Muhammad Ichsan
      ... I agree with this. ... 3 layers not 3 tiers. I think I should use dao since later I can change the implementation of storing object by using alfresco for
      Message 2 of 5 , Jul 4, 2006
        On 7/3/06, William Pietri <william@...> wrote:
        > However, I'd recommend that you change your approach in a few ways.
        >
        > First see if you can keep the Hibernate session open. If we're talking a
        > web application here, this means closing the session after you transmit
        > the response. Then there's no risk of unexpected exceptions, and keeping
        > the session open for a few extra milliseconds is a small price to pay.

        I agree with this.

        >
        > It also sounds like you are implementing a 3-tier architecture in
        > layers. In my experience, that often leads to Martin Fowler's "Anemic
        > Domain Model" anti-pattern, and it's hugely inefficient. In a multi-tier
        > architecture you're obliged to copy your data repeatedly because you're
        > crossing JVM boundaries all the time. But if you just turn the tiers
        > into layers, you end up with a huge amount of unnecessary copying.

        3 layers not 3 tiers. I think I should use dao since later I can
        change the implementation of storing object by using alfresco for
        instance. But thanks for the suggestion :)

        >
        > Instead, consider eliminating the DAO layer, using Hibernate to map your
        > domain objects directly to the database, and moving a lot of the service
        > layer code into the domain objects themselves. You'll end up with a much
        > cleaner model, one that will be easier to test.
        >
        > Third, rather than separating things out via mocks, I'd suggest you test
        > things together when speed allows it. One way to do that with Hibernate
        > is to use an in-RAM database like Hypersonic for most of your tests.
        > Another is to make Hibernate itself pluggable: make a thin persistence
        > interface, then make a Hibernate implementation and one that just stores
        > your "persistent" objects in HashMaps for the duration of the tests.
        > Either approach is fast, and either approach lets you easily try all of
        > your unit tests against particular databases if you'd like to. Of
        > course, you'll still need unit tests for the Hibernate mappings, and I
        > prefer to do those against a real database.
        >
        > Hoping that helps,
        >
        > William
        >

        Thanks William
      Your message has been successfully submitted and would be delivered to recipients shortly.