Announcement Announcement Module
Collapse
No announcement yet.
Lazy Hibernate killer Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • Lazy Hibernate killer

    Hi,
    Can someone suggest a sure-fire way to get Hibernate Lazy fetch serialized correctly with SpringFlex framework? I have just tried Gilead and did get it to work with SpringFlex. Gilead and others (Pimento, dpHibernate) define a servlet in web.xml to handle the traffic. Whereas SpringFlex uses DispatcherServlet and forwards traffic to FlexRemotingServiceExporter/MessageBrokerFactoryBean.

    Any idea on a) how to resolve seemingly different approaches, b) should i consider DTO?

    I'm stuck.

  • #2
    my two cents

    As much of a pain as it might seem up front - I've recently switched from trying to using my hibernatized domain model directly in my client layer and using a DTO approach. Some may refer to DTO as an anti-pattern, and I can clearly see why (you maintain the domain model in two places, the object and in the DTO - ugh) - but using a tool like Dozer it is is very easy to at least map between the two.

    If your dto beans have properties that match by name dozer will recursively map the beans for you - then in your service layer you do the mapping like this:

    public fooDTO getFoo(String foo) {
    Foo foo = fooService.getFoo(foo);
    return (FooDTO)mapper.map(foo, FooDTO.class));
    }

    and on the things where you are returning DTOs you can map from the DTOs back to your domain objects easily as well:

    public void handleFoo(fooDTO fooDTO) {
    Foo foo = (Foo)mapper.map(fooDTO, Foo.class);
    fooService.handleFoo(foo);
    }

    It's not perfect by any stretch of the imagination.

    One project that is interesting that I haven't played with yet is Gilead:

    http://noon.gilead.free.fr/gilead/

    I did play with a project called dpHibernate - but it was very counterproductive and didn't behave properly. If you play with gilead - let me know how it works for you.

    Comment


    • #3
      Thanks Ryan,

      I have been messing with Gilead for days now. There were a few gotchas that i ran into. And there is still one item outstanding (@Transactional) not working. But if I get passed that I'll be sure to do a write-up on it. Maybe I am a lazy programmer and that's the only reason I avoided DTO. But for sure I have spent more time looking for other ways Does Dozer help any with Actionscript3 generation?

      Yev

      Comment


      • #4
        On a recent project, we started out using DTO and Assembler to map between the domain and the DTO layer. The overall impression was that we had too much work maintaining both sides and the mapping layer.

        I remember we had a brief look at Dozer but decided not to go for it (I don't remember the exact reason).

        Right now we just map directly onto the domain model. We sometimes have to add getters and setters were we would normally not have them. I understand this takes away some of the safety of the domain model in some cases, but the net result is that you save tons of time.

        My 2 cents,
        Christophe

        Comment


        • #5
          Hi Christophe,

          When using a DTO (with Dozer) i understand that one would "skip" on mapping of lazy-loaded Hibernate collection bags. How does one update an entity that had those skipped collections on the way back? Did you do a merge?

          Gilead passes some tokens around between client and server, allowing it to reassemble a pojo to the previous state before it was serialized on its way to client. It brings back collection proxies stored in http session (if i'm not mistaken).

          btw, your Prana framework is kick ass I love it. Started using it, and don't notice any start-up slowness at all, but so far i only have a few beans in it.

          Yev

          Comment


          • #6
            someone must have a better option than a DTO

            Originally posted by cherreman View Post
            On a recent project, we started out using DTO and Assembler to map between the domain and the DTO layer. The overall impression was that we had too much work maintaining both sides and the mapping layer.

            I remember we had a brief look at Dozer but decided not to go for it (I don't remember the exact reason).

            Right now we just map directly onto the domain model. We sometimes have to add getters and setters were we would normally not have them. I understand this takes away some of the safety of the domain model in some cases, but the net result is that you save tons of time.

            My 2 cents,
            Christophe
            Let me first state that I'm not a huge fan of the DTO pattern (lets face it, a dumb object that exists soley for passing data around and not doing anything on that data is hard to justify in an a pure OOP word - and it reeks of procedural programming) - in fact, I quite hate the burden that it has. I think it could be made less of a pain with some tooling support (eg generate dto's automatically based on the domain model - possibly using some annotations to hint at certain properties to be used in the generation property) - but it will always be a pain.

            http://hibernate4gwt.sourceforge.net...azy_issue.html is from the gilead project when it used to be known as hibernate4gwt - but it pretty much shows the issues using dozer.

            Right now - we are not doing the clone option - we've made some compromises on our object graph to break some associations (yeah, not ideal) and yes - it does throw down the whole graph (ugh) - so we're going to look into changing this in the future.

            The reason we got to this point was because I started with using dpHibernate and it's built-in [managed] notations to allow for it to transparently lazy-load collections - the problem was that it didn't work reliably for us and rather than spend forever trying to fix it we punted and went to the tried-and-true (albeit pain-in-the-rear) DTO method.

            Even though it is a pretty big pain - it's still less of a pain than transforming all of our objects into some xml structure and then deconstructing it on both ends - and still less of a pain than some of the other options out there.

            If I were to start a new project that I didn't have tight deadlines on - I think the payout from something like Gilead could be tremendous and I'd put some time into fixing any bugs that I did find with Gilead to make it work the way I want.

            That's why I'm hoping that everyone ELSE will start to use Gilead so that I can point to it and say "Hey, lets use this" to the other developer and have some proven examples and some goed demos - who is even more skeptical of anything but the DTO pattern (partly because he came on right as I was in the middle of this dpHibernate mess so I had some egg on my face from that).

            I'm assuming you can mark some fields in your object model to not ever be passed down to the client using Gilead. That combined with the upcoming spring-security integration with blazeds which should (it seems) allow you to annotate method level security and integrate with flex quite easily for your service calls should make it a pretty good combo.

            Comment


            • #7
              GraniteDS

              Looks that http://www.graniteds.org has far more superior solution regarding flex JPA usage.

              Comment


              • #8
                We have currently 2 running projects, one build with the DTO pattern and the other using gilead.

                We didn't have much trouble using gilead, it works like a charm. Just know your hibernate stuff and its easy to configure. It really saved us lots of code and time.

                All our one to many and many to many collection in hibernate are lazy by default, which means none of them are mapped in the corresponding actionscript classes. What we actually did is making a object pool on the client side. The only purpose of this object pool is to make sure we don't have multiple instances of the same object (that is a new object with the same identifier from the server).

                Also the actionscript side of the domain objects do have a getter and setter property for the list (which is lazy and not send to the client). When calling the getter for the first time some abstract code calls a service at the backend and fills the actionscript object with the list from the server. About 90% of this is in abstract classes.

                Comment

                Working...
                X