Announcement Announcement Module
Collapse
No announcement yet.
Spring vs. I Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • Spring vs. I

    Hi guys,
    Reading & researching about spring framework I realized that the IoC concept is GREAT, but beside that, there is a lot of work & effort that you have to put into xml config files to declare bean structures, each behavior exposed, properties, transactions, security, etc.

    then, I should choose between pay the price mixing some logic with tier communication or implement IoC concept maintaining large xml files.

    why large ?
    To describe you my business, we have like 500 tables in the oracle with 300 business logic objs and you can do the multiplication of the behaviors exposed.
    now, If I have to expose those biz logic I will need buy 100 HD RAID to hold the config/s file of spring (being exaggerated)

    Am I correct about the spring effort ?
    I'm just a newbie in spring, that's why I can have a wrong idea about spring implementation.

    Thank you.

    Rodrigo

  • #2
    I think there are a million and one articles out there that will tell you why you should use spring. I have to say the configuration requirements have never put me off using spring.

    The configuration has to be done anyway either in code or XML. 2.0 has introduced lots of XML short cuts and there are also numerous other ways of cutting down the configuration. (annotations, auto wiring, inner beans etc...)

    I've seen have seen systems using hundreds of tables, domain objects and services. I can honestly say that Spring didn't make the situation any more complicated. It reduced the complexity and enabled us to remove in-house rolled services.

    When I write a new system and if Spring is appropriate, (and given its modular nature, lots of times it is,) I won't be worrying about the size of the configuration I'll be worrying about my customers bizarre requirements.

    Comment


    • #3
      Originally posted by rasensio View Post
      Hi guys,
      Reading & researching about spring framework I realized that the IoC concept is GREAT, but beside that, there is a lot of work & effort that you have to put into xml config files to declare bean structures, each behavior exposed, properties, transactions, security, etc.
      Spring 2.0 allows you to create 'macros' for that. See http://www.springframework.org/docs/...sible-xml.html for more info. This is very useful if you have a lot of beans that look alike.

      then, I should choose between pay the price mixing some logic with tier communication or implement IoC concept maintaining large xml files.

      why large ?
      To describe you my business, we have like 500 tables in the oracle with 300 business logic objs and you can do the multiplication of the behaviors exposed.
      now, If I have to expose those biz logic I will need buy 100 HD RAID to hold the config/s file of spring (being exaggerated)
      Not necessarily. You can do all kinds of tricks in Spring. You could for example dynamically discover your business logic and create those beans at runtime.

      Am I correct about the spring effort ?
      I'm just a newbie in spring, that's why I can have a wrong idea about spring implementation.
      I think if you ask a more concrete question then we can definately point you in the right direction.

      Spring does many things. And possibly a lot of things that can help you to better structure/organize your application.

      S.

      Comment


      • #4
        as karldmoore said, I also want to be worried about what my customers want, not how to deal with configurations.

        I will read more about spring to realize if spring is really what I need.

        Thank you for the responses.

        Comment


        • #5
          Originally posted by rasensio View Post
          as karldmoore said, I also want to be worried about what my customers want, not how to deal with configurations.
          And this is where the non-invasiveness of Spring kicks in. Spring does not intrude anywhere into your business logic. So once u have the IoC infrastructure and bean configurations in place, things really work like a charm and you can fully concentrate on modeling your domain.

          Cheers.

          Comment


          • #6
            Originally posted by debasishg View Post
            And this is where the non-invasiveness of Spring kicks in. Spring does not intrude anywhere into your business logic. So once u have the IoC infrastructure and bean configurations in place, things really work like a charm and you can fully concentrate on modeling your domain.
            Cheers.
            Agreed. Thats obviously intended, but one of its greatest strengths. Looking at the code, you can't tell that Spring is even involved. I think we had a handful of references to Spring in the last project. Its a small price to pay for the problems it solved.

            When you do look into Spring, bare in mind that you don't have to use it all. Its modular so you can use as little or as much as you want. Again another great feature.

            Are there some specific questions you are trying to answer regarding Spring?

            Comment


            • #7
              The truth is that I have my life solved with a very nice framework that send from faxes to rockets to the moon.
              But also I try to be up to date with technologies and spring seems that is here to stay.
              That's why I'm interested in learn it.

              Thank you all.
              Rodrigo

              Comment


              • #8
                Actually, everything that Spring does is simply something that needs to be done somewhere. You need to define your transactions and security somewhere. You need to define your dependencies and dependencies of your dependencies somewhere.

                Xml is more verbose then pure Java code, but I'd say if you would need 100Gb for Spring Xmls you would also need at least 75Gb for equivalent configuration with no Spring.

                To define a bean you need one line of xml. To define a dependency to that bean you need one line of xml. To define transactional behavior of your methods you need one line annotation per method + one line of xml for whole application. I really don't see how can one line of anything be optimized without leaving it out.

                Comment


                • #9
                  Don't know about the Gb estimates, but I agree with the rest of it.

                  Comment


                  • #10
                    I really see the value of IoC non intrusive and also "plug-in" different layers in each tier.
                    and yes, it have to be done in somewhere, and if you can replace a part easily, yes, have to be better.

                    Comment


                    • #11
                      Originally posted by dejanp View Post
                      Xml is more verbose then pure Java code, but I'd say if you would need 100Gb for Spring Xmls you would also need at least 75Gb for equivalent configuration with no Spring.
                      And as well as just considering LOC arguments, you have to bear in mind that Spring configuration is not *code*. The Spring XML "language" is minimally complex and expressive, and very amenable to being processed by tools, unlike the equivalent Java. Even if the XML code were twice the bulk, you would have to consider that by taking particular definitions from a more expressive to a less expressive environment you have made a big gain.

                      And actually I think all things considered, modern Spring auto-proxying stuff &c will on balance actually *reduce* the size of complex applications - this becomes a constant cost that does not scale with the model size.

                      There is a fair "XML backlash" going on at the moment, with Javaites being panned for their lack of DSLs etc. by the declarative types. Bulky and unmanageable schemas such as BPEL, XMI etc. have also contributed to give XML configuration a bad name, but actually I believe Spring's use of XML is really pretty benign, even if it weren't helped along by increasingly great tools.

                      In case anyone had missed it, I should point out that SpringIDE is now really pretty stable and capable - http://springide.org/ - just a taste of what is coming down the tool chain.

                      Comment


                      • #12
                        IMHO, there is also the learning curve aspect in this "is it worth it" discussion. Once you get past the initial curve, it becomes relatively straightforward to add another business service bean to your spring config file.

                        Comment


                        • #13
                          Originally posted by Bosmon View Post
                          And actually I think all things considered, modern Spring auto-proxying stuff &c will on balance actually *reduce* the size of complex applications - this becomes a constant cost that does not scale with the model size.
                          Absolutely. One of my applications lost some 20% on size, just by porting to Spring 1.1 (and Spring 1.1 xml was really verbose).

                          Comment


                          • #14
                            Sure, I will have a learning curve in any third party framework or tool. I really don't care about that. If it is worth, yes, I will pay the price of the learning curve.

                            The good thing that I hear about you is that everybody is happy using Spring and that talks very good about the framework.

                            Comment

                            Working...
                            X