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

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

Expand Messages
  • 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 1 of 5 , Jul 4 3:09 AM
    • 0 Attachment
      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.