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

  • #31
    Originally posted by debasishg View Post
    Isn't one of the most important criteria of an object being a POJO is easy unit-testability of the class, without any dependence on external frameworks ?
    Testable, yes. As of dependencies: I think it's more about dependencies of the class, not dependencies of the test that matter here.

    Besides that, if you once decide to use a different testing framework you can schedule the change for yourself and you wont break any production code.
    If you have, however, a productive application and try to remove its underlying framework and replace it by something else this is a major thing.

    So the difference is, dependencies in testing code may hurt you, dependencies in production code may hurt you and your users, too.

    Regards,
    Andreas

    Comment


    • #32
      Originally posted by debasishg View Post
      Isn't one of the most important criteria of an object being a POJO is easy unit-testability of the class, without any dependence on external frameworks ?
      What I was suggesting though, is that the unit tests themselves are the things with the dependencies e.g. is it acceptable to reference PlatformTransactionManager. I don't want this in my code, but if I need it to test some code I don't mind the dependency in the unit test.

      Originally posted by Andreas Senft View Post
      Testable, yes. As of dependencies: I think it's more about dependencies of the class, not dependencies of the test that matter here.

      Besides that, if you once decide to use a different testing framework you can schedule the change for yourself and you wont break any production code.
      If you have, however, a productive application and try to remove its underlying framework and replace it by something else this is a major thing.

      So the difference is, dependencies in testing code may hurt you, dependencies in production code may hurt you and your users, too.
      Exactly!
      Last edited by karldmoore; Aug 29th, 2007, 12:36 PM.

      Comment


      • #33
        In my book, the whole idea behind POJOs is that they should only contain the business logic that is relevant to them, and nothing else. That's what would constitute a pure POJO. The reason I love Spring is because it provides nice and elegant ways of separating concerns. You put your business logic into a POJO, and keep your configuration, transaction demarcation, etc. elsewhere, outside your code. I don't like using annotations for the very reason that they bring the stuff - unrelated to the business logic - back into your code.

        Comment


        • #34
          Originally posted by constv View Post
          In my book, the whole idea behind POJOs is that they should only contain the business logic that is relevant to them, and nothing else. That's what would constitute a pure POJO. The reason I love Spring is because it provides nice and elegant ways of separating concerns. You put your business logic into a POJO, and keep your configuration, transaction demarcation, etc. elsewhere, outside your code. I don't like using annotations for the very reason that they bring the stuff - unrelated to the business logic - back into your code.
          2 remarks
          1. Term POJO, as it was introduced, had a strictly technical meaning, not related to kind of logic implemented in it. It just means that object is not required to extend prespecified classes, implement prespecified interfaces or use prespecified annotations(!). Last part of previous statement sometimes is questioned (as in this thread).
          2. As I have stated many times that transactionality often is a part of the business logic despite popular misbelief.

          Regards,
          Oleksandr

          Comment


          • #35
            Originally posted by al0 View Post
            2 remarks
            1. Term POJO, as it was introduced, had a strictly technical meaning, not related to kind of logic implemented in it. It just means that object is not required to extend prespecified classes, implement prespecified interfaces or use prespecified annotations(!). Last part of previous statement sometimes is questioned (as in this thread).
            2. As I have stated many times that transactionality often is a part of the business logic despite popular misbelief.

            Regards,
            Oleksandr

            1. Well, technically, you are correct. But the whole point of using a plain object that is not tied to any kind of predefined technology, remote interfaces, etc. Generally, any class should only serve one particular purpose. In practice, using POJOs to implement business functionality implies that they should contain the pure business logic that relates to that specific functionality.

            2. Transactinality is part of the business context, not the business logic. The same operation may or may not have to be transactional. A set of business operations may or may not be related for different use cases/business scenarios, and therefore may be implemented in different classes but be a part of the same transaction in one scenario, and have nothing to do with each other in another. It is absolutely fair, therefore, not to couple transaction demarcation with a particular the business logic unit.

            Comment


            • #36
              Originally posted by constv View Post
              In my book, the whole idea behind POJOs is that they should only contain the business logic that is relevant to them, and nothing else. That's what would constitute a pure POJO. The reason I love Spring is because it provides nice and elegant ways of separating concerns. You put your business logic into a POJO, and keep your configuration, transaction demarcation, etc. elsewhere, outside your code. I don't like using annotations for the very reason that they bring the stuff - unrelated to the business logic - back into your code.
              I don't mean to be ignorant, but which book is your book . The transction poll has picked up on the annotation point as well. It would be great if you could add your opinion to that discussion!
              http://forum.springframework.org/showthread.php?t=37178
              Last edited by karldmoore; Aug 29th, 2007, 12:36 PM.

              Comment


              • #37
                "In my book" = "as far as I'm concerned"... No, I haven't written a book on POJOs.

                Comment


                • #38
                  Originally posted by constv View Post
                  "In my book" = "as far as I'm concerned"... No, I haven't written a book on POJOs.
                  Sorry it must really be late . I thought you were some kind of expert on the subject who'd written a book. That confirms it, I need to go to bed .
                  Last edited by karldmoore; Aug 29th, 2007, 12:35 PM.

                  Comment


                  • #39
                    Well, I didn't say I wasn't an expert...

                    Comment


                    • #40
                      Originally posted by constv View Post
                      2. Transactinality is part of the business context, not the business logic. The same operation may or may not have to be transactional. A set of business operations may or may not be related for different use cases/business scenarios, and therefore may be implemented in different classes but be a part of the same transaction in one scenario, and have nothing to do with each other in another. It is absolutely fair, therefore, not to couple transaction demarcation with a particular the business logic unit.
                      I think it would help should we define expressions we are using. I have a bad feeling - there are as many definitions of what is 'business logic' as senior developers out there. Now we have 'business context' vs. 'business logic'.

                      Comment


                      • #41
                        Originally posted by Arno Werr View Post
                        I think it would help should we define expressions we are using. I have a bad feeling - there are as many definitions of what is 'business logic' as senior developers out there. Now we have 'business context' vs. 'business logic'.
                        I'm not sure what puzzles you. Business context is the context of your particular use case (business case, or whatever you want to call it.) The logic is the sequence of steps and algorithms you provide to implement a particular task or set of tasks. A "transaction" as an entity encloses some business logic (set of tasks that must complete within it), but transaction demarcation is not business logic. So, we are talking about decoupling transaction demarcation from the implementation of the bits of logic that may or may not constitute a transaction - depending on the use case. That's absolutely fair, and its a good way to go about it.

                        Cheer,
                        Constantine

                        Comment


                        • #42
                          Originally posted by constv View Post
                          I'm not sure what puzzles you. Business context is the context of your particular use case (business case, or whatever you want to call it.) The logic is the sequence of steps and algorithms you provide to implement a particular task or set of tasks. A "transaction" as an entity encloses some business logic (set of tasks that must complete within it), but transaction demarcation is not business logic. So, we are talking about decoupling transaction demarcation from the implementation of the bits of logic that may or may not constitute a transaction - depending on the use case. That's absolutely fair, and its a good way to go about it.

                          Cheer,
                          Constantine
                          Have to disagree with you - quite often each of these steps has no business meaning as soon as not all of steps are completed. This is a very reason for transaction - it represents an operation that is atomic from business point of view. The fact that you shall to perform several technical (technical not from progammrers point of view, but from customers point of view) steps is just implementation detail. The rule "all or nothing" is a business rule.

                          Regards,
                          Oleksandr

                          Comment


                          • #43
                            Originally posted by al0 View Post
                            Have to disagree with you - quite often each of these steps has no business meaning as soon as not all of steps are completed. This is a very reason for transaction - it represents an operation that is atomic from business point of view. The fact that you shall to perform several technical (technical not from progammrers point of view, but from customers point of view) steps is just implementation detail. The rule "all or nothing" is a business rule.

                            Regards,
                            Oleksandr
                            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

                            Comment


                            • #44
                              Originally posted by al0 View Post
                              The rule "all or nothing" is a business rule.
                              I agree to that. I think a point here is that this business rule is usually implemented by using technical transactions. And for doing this you may tie your POJO (otherwise containing only business-related logic) to a specific transaction-managing technology (as Spring's tx annotations).

                              So it's not about specifying transactional boundaries in your POJOs, but specifying implementation-dependent transaction boundaries.
                              I would say when transaction related annotations would be part of the Java SDK (allowing for pluggable implementations behind the scenes) then everything would be fine.

                              Regards,
                              Andreas

                              Comment


                              • #45
                                Originally posted by al0 View Post
                                The rule "all or nothing" is a business rule.
                                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.

                                Comment

                                Working...
                                X