Announcement Announcement Module
Collapse
No announcement yet.
Is Annotated POJO a POJO ? Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • #46
    Originally posted by constv View Post
    Exactly. Business rules may change, they depend on different scenarios, and you want the core of your logic to be reusable. That's why I keep saying that there's a difference between a business requirement and pure logic that, ideally, should be reusable within different scenarios. Of course, there are cases when certain logic is meant to be used in only one particular scenario and that's it. But we are talking about general cases here, aren't we.

    I prefer declarative transaction demarcation vs. annotations b/c annotations are still part of your source code.
    I dare to suggest to put its Java statement is a separate modul for better modularity.

    Comment


    • #47
      Originally posted by constv View Post
      I don't see any point in arguing any further. You can apply the same argument to exception handling, and I would disagree. In some cases, it is a business requirement to wrap a particular piece of logic in an error-handling construct, in some cases it must be done on a higher level. No one argues - I think - that separating such concerns as error handling and pure business logic is a good idea. Transaction demarcation is the same thing. When you are weaving your transaction demarcation into your code, you, by definition, make this code not reusable in other business cases that may just need parts of it - in a different transactional context, or in a non-transactional context. This also assumes that your code becomes less modular.

      Piece,
      Constantine
      You are wrong - the same argument can not be applied to exception handling. Unlike to transaction event handling is just implementation tool. Business requirement is to recognize and handle different situations. How you do it - it is your problem and decision, by exception handling, return codes or in some more exotic way.

      And I may ensure you that so-called "core business logic" changes much more frequently then business rules concerning transactionality.

      Regards,
      Oleksandr

      Comment


      • #48
        Originally posted by al0 View Post
        You are wrong - the same argument can not be applied to exception handling. Unlike to transaction event handling is just implementation tool. Business requirement is to recognize and handle different situations. How you do it - it is your problem and decision, by exception handling, return codes or in some more exotic way.

        And I may ensure you that so-called "core business logic" changes much more frequently then business rules concerning transactionality.
        Exactly! Exceptions that are handled within domain-layer POJOs are part of business rules/logic. Hence handling them very much belongs to the business layer. And the handling mechanism is undoubtedly a native JDK thing. OTOH transactions are ways to implement the all-or-nothing rule. Atomicity is part of the business rule - how we implement using transactions is an entirely implementation artifact and should ideally *NOT* be part of the POJOs.

        Cheers.
        - Debasish

        Comment


        • #49
          Originally posted by debasishg View Post
          Exactly! Exceptions that are handled within domain-layer POJOs are part of business rules/logic. Hence handling them very much belongs to the business layer. And the handling mechanism is undoubtedly a native JDK thing. OTOH transactions are ways to implement the all-or-nothing rule. Atomicity is part of the business rule - how we implement using transactions is an entirely implementation artifact and should ideally *NOT* be part of the POJOs.

          Cheers.
          - Debasish
          No one argues with the fact that a business case may require transactions and error handling. C'mon! The question is whethere it is a clearer and more flexible approach to isolate that in a sincle code/configuration snippet rather then weaving it into the code and duplicating the same Tx/Exception handling code for every method that qualifies.

          This has turned into a pi$$ing contest, and I am out of it. Cheers!

          Comment


          • #50
            Originally posted by constv View Post
            No one argues with the fact that a business case may require transactions and error handling. C'mon! The question is whethere it is a clearer and more flexible approach to isolate that in a sincle code/configuration snippet rather then weaving it into the code and duplicating the same Tx/Exception handling code for every method that qualifies.

            This has turned into a pi$$ing contest, and I am out of it. Cheers!
            Real question is slightly different - should important (probably, the most important) part of the method contract be isolated from the method?
            In my book - no and once more no.

            It does not mean that handling code shall be present there, just "declaration of intention" (e.g. annotation).

            And do not try to mix-in exception handling in this discussion as exception handling is no more then syntactycally sugared way to express trivial "if".

            Regards,
            Oleksandr

            Comment


            • #51
              Originally posted by cepage View Post
              This means no annotations, not even my beloved @Configurable
              Just going back to an earlier discussion, if we haven't got @Configurable what's the alternative approach? How to we achieve the same thing in a POJO way?
              Last edited by karldmoore; Aug 29th, 2007, 11:35 AM.

              Comment


              • #52
                Originally posted by karldmoore View Post
                Just going back to an earlier discussion, if we haven't got @Configurable what's the alternative approach? How to we achieve the same thing in a POJO way?
                Karl -

                I think you can subclass the abstract Spring aspect AbstractBeanConfigurerAspect. Using this, u you can write an aspect to configure all instances of objects defined in the domain model using prototypical bean definitions that match the fully-qualified class names. Please have a look at section 6.8.2 in Spring 2.0.4 docs. Last year I had blogged about this .. have a look at the comments where I discuss this.

                Of course this is only valid if u consider adding aspects to a POJO as NOT violating its POJO behavior.

                Cheers.
                - Debasish

                Comment


                • #53
                  Originally posted by debasishg View Post
                  Of course this is only valid if u consider adding aspects to a POJO as NOT violating its POJO behavior.
                  Thanks for that, I'll check out your blog. After the whole dependency debate, I just thought it was interesting to know what the alternative is to @Configurable. I would have thought this is a pretty important feature. People want rich domain models made up of POJOs but don't want to be tied to Spring! If we are dealing with aspects then we don't have to modify the POJOs, sounds like it fits the bill.

                  This presentation also had some examples of this.
                  http://www.bejug.org/confluenceBeJUG...wComments=true
                  Last edited by karldmoore; Aug 29th, 2007, 11:35 AM.

                  Comment


                  • #54
                    Saw this and though it was interesting.
                    http://jroller.com/page/eu?entry=damned_guice
                    Last edited by karldmoore; Aug 29th, 2007, 11:34 AM.

                    Comment


                    • #55
                      New feature

                      I posted the new feature http://jira.springframework.org/browse/SPR-4602.

                      Comment

                      Working...
                      X