6 ms·

The Spring that I've used (the DI Framework, Spring Integration, Spring MVC) is mainly designed to simplify and standardize enterprise applications. Mostly thi

by cle 10y ago

The Spring that I've used (the DI Framework, Spring Integration, Spring MVC) is mainly designed to simplify and standardize enterprise applications. Mostly this involves standard and automated ways to "wire" together applications. This includes DI, but also includes configuration (e.g. configuration to enable a deployment pipeline), communication between components/services (client and server mapping of messages in a message bus to their ser/de impl and schema definitions, database interfaces), service and UI implementations themselves (SpringMVC, Spring Boot), etc. The benefit is that Spring is a glue layer that integrates all these various pieces of "enterprise" systems with minimal boilerplate. I don't have much experience with Java EE, so can't comment. My experience with Spring is not very positive--it enables and encourages applications and systems to have complex dependency graphs, and so often I've seen this result in giant balls of mud that, despite Spring's claim that it enables decoupled and modularized design, are rat's nests of unexpected coupling and hard-to-predict behavior.

ivan_gammel 10y ago
Spring (and latest JEE editions with better support of DI) no more encourages spaghetti designs than does manual wiring of objects, so usually these giant balls of mud are the result of project management and design mistakes, not the failure of the tool. In fact, properly designed system that uses DI is indeed decoupled (because you can limit the number of interfaces between components) and modularized (because you can wire dependency of one module on interface with implementation in another one). Moreover, it opens the way to plugin architecture, because application context definition can serve also as plugin definition and there exists discovery mechanism (e.g. classpath:/plugins/*.xml in plain DI or Spring Boot AutoConfiguration).
- jacques_chester 10y ago
  I think maybe this comes down to the kind of injection. If you rely on variable or setter injection, you can easily create a kind of dark matter that invisibly warps the flexibility of the project. I and others have generally found that using Constructor injection greatly decouples a design and simplifies testing. And the Spring team have been saying so for at least as long as I've paid attention to the question[0]: > Constructor-based or setter-based DI? > ... > The Spring team generally advocates constructor injection as it enables one to implement application components as immutable objects and to ensure that required dependencies are not null. Furthermore constructor-injected components are always returned to client (calling) code in a fully initialized state. > ... [0] https://docs.spring.io/spring/docs/current/spring-framework-reference/html/beans.html#beans-setter-injection https://docs.spring.io/spring/docs/current/spring-framework-...
  - ivan_gammel 10y ago
    Nope. There is no difference between injection types from the coupling perspective, simply because neither blocks anything bad from happening in your architecture. There are reasons to prefer constructor injection in many cases, but it has nothing to do with modularity or coupling.
    - jacques_chester 10y ago
      I disagree. Constructor injection in Spring is more test-friendly; in turn that tends to allow us the liberty of more aggressively modularising the design. With other injection types either more bookkeeping is required to cleanly set up tests; or alternatively, "unit" testing becomes more integration-esque. It's a second-order effect felt in the many small decisions that lead one to the mudpit. That's why I used the analogy of dark matter. It's not directly observed, but it has gravity.
      - twic 10y ago
        > Constructor injection in Spring is more test-friendly If you get in the habit of using the Spring test support, where classes under test get injected, then all kinds of injection are equally friendly, and the tests don't give you feedback on the weight of the dependencies because Spring does the heavy lifting. And, in my experience, where you do inject dependencies by hand, the design pressure is actually towards coarser-grained objects. Why? Because you need to have enough functionality to test; with fine-grained objects, you have to construct and assemble an object graph in the test, whereas with coarse-grained objects, you just new up one thing.
        EdwardDiego 10y ago
        > If you get in the habit of using the Spring test support, where classes under test get injected, then all kinds of injection are equally friendly, and the tests don't give you feedback on the weight of the dependencies because Spring does the heavy lifting. How do you handle the Spring context start-up time? In Spring projects I've worked on, across hundreds of unit tests it's non-trivial. But I don't make any claim to know if we were doing Spring right or not.
- orless 10y ago
  "... so usually these giant balls of mud are the result of project management and design mistakes, not the failure of the tool." It is the failure of concepts so if the tool brings the right concepts, it helps avoid such design mistakes in the first place.
  - ivan_gammel 10y ago
    That's too generic statement to be applied to anything. Some specific failures of tools (what exactly?) may be the cause of other issues, but it's not the law of nature. You can hit your finger by a hummer, but it's not because hummer brought the wrong concepts - it served millions of people to build their homes, their farms and fences, it's just because sometimes you miss the nail.
    - orless 10y ago
      It is only generic if you completely drop the context of the discussion (Spring and dependency injection). My point is that Spring brings DI/IoC concepts which help build healthy projects.
      - ivan_gammel 10y ago
        There are so many counter-examples in the world of poorly built projects, that I don't really understand how did you came to this conclusion. DI/IoC is just a pattern, there's no way it could guide you to good architecture itself. Spring is just a tool, which adds some constraints, but which does not force you to make business decisions on scope of different domains or interaction between them that might lead to strong coupling and low modularity.
        orless 10y ago
        I'm not sure where I stated that Spring forces "to make business decisions on scope of different domains or interaction between them that might lead to strong coupling and low modularity".
- cle 10y ago
  It enables such designs, by making it easy for someone to add more crap into your ball of mud. Not everyone on your team is as smart or experienced as you. When their back is against the wall with a deadline...just throw some more beans in there, who cares how they're wired together, it's all handled by Spring! Well, you care when you have an unexpected complex circular dependency or you need to refactor and you suddenly discover how complex your dependency graph has unintentionally become. By "decoupling" and "modularization", I'm not talking about at a code-level by using interfaces. In my opinion, that kind of decoupling and modularization isn't very important, especially when it comes to application glue--because the glue (Spring) is what decides the backing impl's of all those interfaces. That's where the important dependencies lie, and that's where your big ball of mud accretes.
  - ivan_gammel 10y ago
    It is not a tool problem. Programming tools always address two problems: coding performance and coding quality. But the design, the architecture is not something that could be fixed by a tool. Frameworks may add or remove some constraints, but there's always enough space for the side effects of human creativity. People always break or misuse the tools, creating the balls of mud. It's not a problem with these tools, it's a problem with organization of development process, with competencies of decision makers, with inadequate constraints and unclear requirements. It's easy to blame the tool, throw away the ball of mud and start from scratch with fancy new tech. But in the end you'll get the same ball of mud, because you have ignored the root causes.
  - kazagistar 10y ago
    > When their back is against the wall with a deadline...just throw some more beans in there, who cares how they're wired together, it's all handled by Spring! I just came across a controller in our code that had over 50 spring injected services. Our entire code base is only like 5 years old. The problem is that this is my first job out of college... even if I know things are messed up, I don't really have an example of an application like this that is actually done right.
    - qw 10y ago

by cle 10y ago

ivan_gammel 10y ago

Spring (and latest JEE editions with better support of DI) no more encourages spaghetti designs than does manual wiring of objects, so usually these giant balls of mud are the result of project management and design mistakes, not the failure of the tool. In fact, properly designed system that uses DI is indeed decoupled (because you can limit the number of interfaces between components) and modularized (because you can wire dependency of one module on interface with implementation in another one). Moreover, it opens the way to plugin architecture, because application context definition can serve also as plugin definition and there exists discovery mechanism (e.g. classpath:/plugins/*.xml in plain DI or Spring Boot AutoConfiguration).

jacques_chester 10y ago
I think maybe this comes down to the kind of injection. If you rely on variable or setter injection, you can easily create a kind of dark matter that invisibly warps the flexibility of the project. I and others have generally found that using Constructor injection greatly decouples a design and simplifies testing. And the Spring team have been saying so for at least as long as I've paid attention to the question[0]: > Constructor-based or setter-based DI? > ... > The Spring team generally advocates constructor injection as it enables one to implement application components as immutable objects and to ensure that required dependencies are not null. Furthermore constructor-injected components are always returned to client (calling) code in a fully initialized state. > ... [0] https://docs.spring.io/spring/docs/current/spring-framework-reference/html/beans.html#beans-setter-injection https://docs.spring.io/spring/docs/current/spring-framework-...
- ivan_gammel 10y ago
  Nope. There is no difference between injection types from the coupling perspective, simply because neither blocks anything bad from happening in your architecture. There are reasons to prefer constructor injection in many cases, but it has nothing to do with modularity or coupling.
  - jacques_chester 10y ago
    I disagree. Constructor injection in Spring is more test-friendly; in turn that tends to allow us the liberty of more aggressively modularising the design. With other injection types either more bookkeeping is required to cleanly set up tests; or alternatively, "unit" testing becomes more integration-esque. It's a second-order effect felt in the many small decisions that lead one to the mudpit. That's why I used the analogy of dark matter. It's not directly observed, but it has gravity.
    - twic 10y ago
      > Constructor injection in Spring is more test-friendly If you get in the habit of using the Spring test support, where classes under test get injected, then all kinds of injection are equally friendly, and the tests don't give you feedback on the weight of the dependencies because Spring does the heavy lifting. And, in my experience, where you do inject dependencies by hand, the design pressure is actually towards coarser-grained objects. Why? Because you need to have enough functionality to test; with fine-grained objects, you have to construct and assemble an object graph in the test, whereas with coarse-grained objects, you just new up one thing.
      - EdwardDiego 10y ago
        > If you get in the habit of using the Spring test support, where classes under test get injected, then all kinds of injection are equally friendly, and the tests don't give you feedback on the weight of the dependencies because Spring does the heavy lifting. How do you handle the Spring context start-up time? In Spring projects I've worked on, across hundreds of unit tests it's non-trivial. But I don't make any claim to know if we were doing Spring right or not.
orless 10y ago
"... so usually these giant balls of mud are the result of project management and design mistakes, not the failure of the tool." It is the failure of concepts so if the tool brings the right concepts, it helps avoid such design mistakes in the first place.
- ivan_gammel 10y ago
  That's too generic statement to be applied to anything. Some specific failures of tools (what exactly?) may be the cause of other issues, but it's not the law of nature. You can hit your finger by a hummer, but it's not because hummer brought the wrong concepts - it served millions of people to build their homes, their farms and fences, it's just because sometimes you miss the nail.
  - orless 10y ago
    It is only generic if you completely drop the context of the discussion (Spring and dependency injection). My point is that Spring brings DI/IoC concepts which help build healthy projects.
    - ivan_gammel 10y ago
      There are so many counter-examples in the world of poorly built projects, that I don't really understand how did you came to this conclusion. DI/IoC is just a pattern, there's no way it could guide you to good architecture itself. Spring is just a tool, which adds some constraints, but which does not force you to make business decisions on scope of different domains or interaction between them that might lead to strong coupling and low modularity.
      - orless 10y ago
        I'm not sure where I stated that Spring forces "to make business decisions on scope of different domains or interaction between them that might lead to strong coupling and low modularity".
cle 10y ago
It enables such designs, by making it easy for someone to add more crap into your ball of mud. Not everyone on your team is as smart or experienced as you. When their back is against the wall with a deadline...just throw some more beans in there, who cares how they're wired together, it's all handled by Spring! Well, you care when you have an unexpected complex circular dependency or you need to refactor and you suddenly discover how complex your dependency graph has unintentionally become. By "decoupling" and "modularization", I'm not talking about at a code-level by using interfaces. In my opinion, that kind of decoupling and modularization isn't very important, especially when it comes to application glue--because the glue (Spring) is what decides the backing impl's of all those interfaces. That's where the important dependencies lie, and that's where your big ball of mud accretes.
- ivan_gammel 10y ago
  It is not a tool problem. Programming tools always address two problems: coding performance and coding quality. But the design, the architecture is not something that could be fixed by a tool. Frameworks may add or remove some constraints, but there's always enough space for the side effects of human creativity. People always break or misuse the tools, creating the balls of mud. It's not a problem with these tools, it's a problem with organization of development process, with competencies of decision makers, with inadequate constraints and unclear requirements. It's easy to blame the tool, throw away the ball of mud and start from scratch with fancy new tech. But in the end you'll get the same ball of mud, because you have ignored the root causes.
- kazagistar 10y ago
  > When their back is against the wall with a deadline...just throw some more beans in there, who cares how they're wired together, it's all handled by Spring! I just came across a controller in our code that had over 50 spring injected services. Our entire code base is only like 5 years old. The problem is that this is my first job out of college... even if I know things are messed up, I don't really have an example of an application like this that is actually done right.
  - qw 10y ago