I love the concept of DI and loosely coupled system, a lot. However, I found tooling in Spring lacking at best. For example, it's hard to do "refactoring", e.g. to change a name of a bean declared in Spring. I'm new to Spring, so I would be missing something. There is no compiling time check etc.
My question is why do we want to use XML to store the configuration? IMO, the whole idea of Spring (IoC part) is to force certain creational pattern. In the world of gang-of-four patterns, design patterns are informative. Spring (and other DIs) on the other hand, provides very prescribed way how an application should be hooked up with individual components.
I have put Scala in the title as well as I'm learning it. How do you guys think to create a domain language (something like the actor library) for dependency ingestion. Writing the actual injection code in Scala itself, you get all the goodies and tooling that comes with it. Although application developers might as well bypass your framework, I would think it's relatively easy to standard, such as the main web site/app will only load components of certain pattern.
There's a good article on using Scala together with Spring and Hibernate here.
About your question: you actually can use annotations. It has some advantages. XML, in turn, is good beacause you don't need to recompile files, that contain your injection configs.
There is an ongoing debate if Scala needs DI. There are several ways to "do it yourself", but often this easy setup is sufficient:
//the class that needs injection
abstract class Foo {
val injectMe:String
def hello = println("Hello " + injectMe)
}
//The "binding module"
trait Binder {
def createFooInstance:Foo
}
object BinderImpl extends Binder {
trait FooInjector {
val injectMe = "DI!"
}
def createFooInstance:Foo = new Foo with FooInjector
}
//The client
val binder:Binder = getSomehowTheRightBinderImpl //one way would be a ServiceLoader
val foo = binder.createFooInstance
foo.hello
//--> Hello DI!
For other versions, look here for example.
I love the concept of DI and loosely
coupled system, a lot. However, I
found tooling in Spring lacking at
best. For example, it's hard to do
"refactoring", e.g. to change a name
of a bean declared in Spring. I'm new
to Spring, so I would be missing
something. There is no compiling time
check etc.
You need a smarter IDE. IntelliJ from JetBrains allows refactoring, renaming, etc. with full knowledge of your Spring configuration and your classes.
My question is why do we want to use
XML to store the configuration?
Why not? You have to put it somewhere. Now you have a choice: XML or annotations.
IMO,
the whole idea of Spring (IoC part) is
to force certain creational pattern.
In the world of gang-of-four patterns,
design patterns are informative.
ApplicationContext is nothing more than a big object factory/builder. That's a GoF pattern.
Spring (and other DIs) on the other
hand, provides very prescribed way how
an application should be hooked up
with individual components.
GoF is even more prescriptive: You have to build it into objects or externalize it into configuration. Spring externalizes it.
I have put Scala in the title as well
as I'm learning it. How do you guys
think to create a domain language
(something like the actor library) for
dependency ingestion.
You must mean "injection".
Writing the
actual injection code in Scala itself,
you get all the goodies and tooling
that comes with it.
Don't see what that will buy me over and above what Spring gives me now.
Although
application developers might as well
bypass your framework, I would think
it's relatively easy to standard, such
as the main web site/app will only
load components of certain pattern.
Sorry, I'm not buying your idea. I'd rather use Spring.
But there's no reason why you shouldn't try it and see if you can become more successful than Spring. Let us know how you do.
There are different approaches to DI in java, and not all of them are necessarily based on xml.
Spring
Spring provides a complete container implementation and integration with many services (transactions, jndi, persistence, datasources, mvc, scheduling,...) and can actually be better defined using java annotations.
Its popularity stems from the number of services that the platform integrates, other than DI (many people use it as an alternative to Java EE, which is actually following spring path starting from its 5 edition).
XML was the original choice for spring, because it was the de-facto java configuration standard when the framework came to be. Annotations is the popular choice right now.
As a personal aside, conceptually I'm not a huge fan of annotation-based DI, for me it creates a tight coupling of configuration and code, thus defeating the underlying original purpose of DI.
There are other DI implementation around that support alternative configuration declaration: AFAIK Google Guice is one of those allowing for programmatic configuration as well.
DI and Scala
There are alternative solutions for DI in scala, in addition to using the known java frameworks (which as far as I know integrate fairly well).
For me the most interesting that maintain a familiar approach to java is subcut.
It strikes a nice balance between google guice and one of the most well-known DI patterns allowed by the specific design of the scala language: the Cake Pattern. You can find many blog posts and videos about this pattern with a google search.
Another solution available in scala is using the Reader Monad, which is already an established pattern for dynamic configuration in Haskell and is explained fairly well in this video from NE Scala Symposium 2012 and in this video and related slides.
The latter choice goes with the warning that it involves a decent level of familiarity with the concept of Monads in general and in scala, and often aroused some debate around its conceptual complexity and practical usefulness. This related thread on the scala-debate ML can be quite useful to have a better grip on the subject.
i can't really comment on scala, but DI helps enforce loose coupling. It makes refactoring large apps soooo much easier. If you don't like a component, just swap it out. Need another implementation for a particular environment, easy just plug in a new component.
I agree! To me he way most people use Spring is a mild version of hell.
When you look at the standard Springified code there are interfaces everywhere, and you never really know what class is used to implement an interface. You have to look into some fantastic configuration to find that out. Easy read = not. To make this code surfable you need a very advanced IDE, like Intelly J.
How did we end up in this mess? I blame automated unit testing! If you want to connect mocks to each and every class you can not have dependencies. If it wasn't for unit testing we could probable do just as well without loose coupling, since we do not want the customer to replace single classes willy nilly in our Jars.
In Scala you can use patterns, like the "Cake Patten" to implement DI without a framework. You can also use structural typing to do this. The result is still messy compared to the original code.
Personally I think one should consider doing automated testing on modules instead of classes to escape this mess, and use DI to decouple entire modules. This strategy is by definition not unit testing. I think most of the logic lies in the actual connections between classes, so IMHO one will benefit more from module testing than unit testing.
I cannot agree that XML is problem in Java and Spring:
I use Spring and Java extensively without to much XML because most configuration is done with annotations (type and name is powerful contract) - it looks really nice. Only for 10% cases I use XML because it is easier to do it in XML than code special solution with factories / new classes / annotations. This approach was inspired by Guice and Spring from 3.0 implements its as JSR-330 (but even that I use Spring 2.5 with spring factory configured with JSR-330 annotations instead of default spring-specific #Autowired).
Probably scala can provide better syntax for developing in DI style and I'm looking at it now (pointed Cake Pattern).
Related
When we talk about spring (which ever module say jdbc), one of the reasons we use it is because it enables dependency injection and controls lifecycle of beans/classes. In programming, one of the most important fundamental is to code for interfaces rather than implementations, so today if I am using sql server driver v1, I can change it to v2 tomorrow if my code is written in such a way that it cares about Driver interface and not the implementations, then in what case would I ever need coding over configuration ?
The wording of your question seems a bit strange to me. Perhaps you are asking if there are any drawbacks to using Spring-like dependency injection. I can think of a few drawbacks, but whether these drawbacks outweigh the potential benefits of Spring is a matter of opinion.
Unfortunately, a Spring XML file is much more verbose than code to achieve similar (but hard-coded) initialisation of objects.
A programmer has to look not just at code but also at a Spring XML file to figure out what is going on. This, arguably, is a form of the Yo-yo problem.
One significant benefit of Spring is that it can be used to instantiate and configure any Java class (assuming the classes provide getters and setters). In particular, Java classes do not need to be polluted with the need to inherit from framework infrastructure classes. If you don't mind polluting classes with the need to inherit from framework infrastructure, then it is possible to have much more concise configuration files for instantiating and configuring objects. A case study illustrating this idea can be found in Chapters 9, 10 and 11 of the Config4* Practical Usage Guide. I am not proposing that the approach used in that case study be used for all applications, but I think it is a good approach to use when there is a complex, standardised API (such as for JMS) that is implemented by multiple products. In the case study, the approach results in a significantly easier-to-use API and eliminates some potential bugs from applications. Spring doesn't offer such benefits.
Section 9.4.2 of the Config4* Practical Usage Guide outlines a 9-step initialisation process for typical JMS applications. The framework library discussed in the case study ensures that those 9 steps are carried out in the correct order. It has been years since I looked at Spring so I might be wrong, but I don't think Spring has the flexibility to (easily or perhaps at all) enforce such a complex 9-step initialisation mechanism.
I have read that dependency injection is good for testing, in that a class can be tested without its dependencies, but the question comes to my mind if Class A depends on Class B or C or any class, testing Class A independent of some class is yielding a test result of zero, not a failed or past test.
Class A was created to do something and if it is not fed anything whether using new key word or setting up the extra files in Spring, Class A won't do any work.
About the idea of making code modular, readable and maintainable: so business classes became cleaner, but all we did was shift confusion from dirty Java business classes to convoluted XML files and having to delete interfaces used to inject to our loosened objects.
In short, it seems we have to make edits and changes to a file somewhere,right?
Please feel free to put me in my place if my understanding is lacking, just a little irritated with learning Spring because I see the same amount of work just rearranged.
Dependency injection is good for unit testing because you can individually test each method without that method depending on anything else. That way each unit test can test exactly one method.
I would say that if the xml is what’s annoying you check out Spring boot. It’s based on a java configuration so no xml and it simplifies a lot of configuration for you based on your class path. When I first started spring I found the xml very daunting coming from a java background but the annotation based configuration and the auto configuring done by spring boot is extremely helpful for quickly getting applications working.
IMO biggest advantage of using the spring is dependency injection which makes your life easy. For example if you would like to create a new service with three dependencies, then you can create a class very easily using Spring. But without spring, you will end up writing different factory methods which will return you the instances you are looking for. This makes your code very verbose with static method calls. You may want to take a look at the code repositories before spring era.
Again if you would like to use Spring or not is your personal call based on project complexity. But it's other features/advantages cant be overlooked.
And XML files or Java configs are the ways of achieving spring configuration - where you would like to add your business logic is personal flavour. Only thing is you should be consistent all across your project.
I would suggest that you read Martin Fowler's great article on Inversion of Control and Dependency Injection to gain a better understanding of why frameworks like Spring can be really useful to solve a well known set of common dependency injection problems when writing software.
As others have mentioned, there is no obligation to use Spring; and whatever you can do with Spring, you can probably do it by other means like abstract factories, factory methods, or service locators.
If your project is small enough, then you probably wouldn't mind solving the dependency injection issues on your own using some design patterns like those mentioned above. However, depending on the size of your project, many would prefer to use a framework or a library that already packs a bunch of solutions to these recurrent head scratchers.
In regards to the advantages of dependency injection frameworks when doing unit testing is the idea that you don't need to test the dependencies of your class, but only your class.
For example, most likely your application has a layered design. It is very common to have a data access class or a repository that you use to retrieve data from a datasource. Logically, you also have a class where you use that DAO.
Evidently, you already wrote unit testing for your DAO, and therefore, when you're testing your business class (where the DAO is being used) you don't care about testing your DAO again.
Fortunately, since Spring requires some form of dependency injection for your DAO, this means your class must provide a constructor or a setter method through which we can inject that DAO into our business class, right?
Well, then during unit testing of your business class, you can conveniently use those injection points to inject your own fake DAO (i.e. a mock object). That way, you can focus on the testing of your business class and forget about retesting the DAO again.
Now compare this idea with other solutions you may have done on your own:
You inject the dependency directly by instantiating the DAO within your business class.
You use a static factory method within your code to gain access to the DAO.
You use a static method from a service locator within your code to gain access to the DAO.
None of these solutions would make your code easy to test because there is no simple manner to get in the way of choosing exactly what dependency I want injected into my business class while testing it (e.g. how do you change the static factory method to use a fake DAO for testing purposes?).
So, in Spring, using XML configuration or annotations, you can easily have different dependencies being injected into your service object based on a number of conditions. For example, you may have some configurations for testing that evidently would be different than those used in production. And if you have a staging environment, you may even have different XML configurations of dependencies for your application depending on whether it is running in production or integration environments.
This pluggability of dependencies is the key winning factor here in my opinion.
So, as I was saying, my suggestion to you is that you first expand your understanding of what problems Spring core (and in general all dependency injection frameworks) is trying to solve and why it matters, and that will give you a broader perspective and understanding of these problems in a way that you could to determine when it is a good idea to use Spring and when it is not.
I m a newbie & i m good at Struts framework. Today i tried a tutorial for Spring MVC Framework.
The example url that i tried following is as below:
http://static.springsource.org/docs/Spring-MVC-step-by-step/part6.html
I think they have made this tutorial much more complex especially near its end. I saw some errors mainly typos in part 5, part 6 of tutorial. I found Spring framework as not properly organized and how would we know what classes to extend especially when their names are so weird (pardon my language) e.g. AbstractTransactionalDataSourceSpringContextTests.
Overall i found that Spring is making things much more complex than it should be. I'm surprised why there is such a hype about Springs being very easy to learn.
any suggestion how to learn spring easily ? how to judge what to extend ? is there a quick reference or something?
The tutorial you have referred to covers all the layers of the application - data access, business logic and web. For someone who is looking to only get a feel of Spring MVC, which addresses concerns specific to the web layer of the application, this could be more information than required. Probably that is why you got the feeling that the tutorial is complex.
To answer your questions, Spring is easy to learn because the whole framework is designed to work with POJOs, instead of relying on special interfaces, abstract classes or such. Developers can write software as normal Java applications - interfaces, classes and enums and use Spring to wire the components up, without having to go out of the way to achieve the wiring. The tutorial you have referred to tries to explain things in a little bit more detail than experienced programmers would typically do in a real application, probably because the authors wanted the readers to get enough insight into how Spring works so that concepts are understood well.
In most applications (regardless of their size or nature), there is typically no need to extend Spring classes or to implement specialised classes. The Spring community is quite large and an even larger ecosystem of readily available components exists that integrate with Spring. It is therefore very rare that one has to implement a Spring component to achieve something. For example, let us take the example of the data access layer. Different teams like using different approaches to accessing databases. Some like raw JDBC, others like third-party ORMs like iBatis or Hibernate while some others like JPA. Spring distributions contain classes to support all these approaches. Similarly, lets say someone was looking to incorporate declarative transaction management in their application. Again, transaction management can be done in many different ways and a large number of transaction management products are available for people to use. Spring integration is available for most of these products, allowing teams to simply choose which product they want to use and configure it in their Spring application.
Recent Spring releases have mostly done away with extensive XML based configuration files, which being external to the Java code did make Spring application a bit cumbersome to understand. Many things can be done nowadays with annotations. For example,
#Controller
public class AuthenticationController
{
...
}
Indicates that AuthenticationController is a web MVC controller class. There are even ways to avoid using the Controller annotation and follow a convention-over-configuration approach to simplify coding even further.
A good and simple tutorial to Spring MVC is available at http://www.vaannila.com/spring/spring-mvc-tutorial-1.html. This tutorial uses XML based configuration for Spring beans instead of annotations but the concepts remain the same.
I have seen tutorial you follow , Its seems you have follow wrong one first , you first tried to simple one, Instead of tutorials you should go for book first
I recommend you two books to understand the power of Spring
spring in action and spring recipes.
For practical you can use STS a special ide for spring project development.Its have some predefined template you dont't need to write whole configuration yourself.
In starting just see simple tutorials like Spring mvc hello world , form controller than go for big ones
Spring is very cool , All the best.
I am a big fan of Dependency Injection and the Play Framework, but am having trouble seeing how the two could be exploited together.
There are modules for Spring and Guice, but the way that Play works makes it hard for me to see how DI could be beneficial beyond some quite simple cases.
A good example of this is that Play expects JPA work to be done by static methods associated with the entity in question:
#Entity
Person extends Model {
public static void delete(long id) {
em().find(id).remove();
}
//etc
}
So there is no need for a PersonManager to be injected into controllers in the way it might for a Spring J2EE application. Instead a controller just calls Person.delete(x).
Obviously, DI is beneficial when there are interfaces with external systems, as the concrete implementation can be mocked for testing etc., but I don't see much benefit for a self-contained Play application.
Does anyone have any good examples? Does anyone use it to inject a Manager-style class into Controllers so that a number of operations can be done within the same transaction, for example?
I believe from this sentence you wrote:
"Does anyone have any good examples? Does anyone use it to inject a Manager-style class into Controllers so that a number of operations can be done within the same transaction, for example?"
that before answering the DI question I should note something: transactions are managed automatically by Play. If you check the model documentation you will see that a transaction is automatically created at the beginning of a request, and committed at the end. You can roll it back via JPA or it will be rolled back if an exception is raised.
I mention this because from the wording of your sentence I'm not sure if you are aware of this.
Now, on DI itself, in my (not-so-extensive) experience with DI, I've seen it used mainly to:
Load the ORM (Hibernate) factory/manager
Load Service classes/DAOs into another class to work with them
Sure, there are more scenarios, but these probably cover most of the real usage. Now:
The first one is irrelevant to Play as you get access to your JPA object and transaction automatically
The second one is quite irrelevant too as you mainly work with static methods in controllers. You may have some helper classes that need to be instantiated, and some may even belong to a hierarchy (common interface) so DI would be beneficial. But you could just as well create your won factory class and get rid of the jars of DI.
There is another matter to consider here: I'm not so sure about Guice, but Spring is not only DI, it also provides a lot of extra functionalities which depend on the DI module. So maybe you don't want to use DI in Play, but you want to take advantage of the Spring tools and they will use DI, albeit indirectly (via xml configuration).
The problem in my humble opinion on the static initialization approach of Play! is that it makes testing harder. Once you approach the HTTP vs Object Orientation problem with static members and objects that carries the HTTP message data (request and response) you make a trade of having to create new instances for each request by the ability of make your objects loosely coupled with the rest of your project classes.
One good example of a different design are servlets, it also extends a base class but it approaches the problem with a single instance creation (by default, because there are configurations that enable more instances).
I believe that maybe a mix of the two approaches would be better, having a singleton of each controller would give the same characteristics of a full static class and would allow dependency injection of some kinds of object. But not the objects with request or session scope, once the controller would need to be created every new request. Moreover it would improve testability by inverting the control of dependency injection, thus allowing arbitrary injection points.
Dependencies would be injected by the container or by a test, probably using mocks for the heavy stuff that much likely would already have been tested before.
In my point of view, this static model pushes the developer away from testing controllers because extending FunctionalTest starts the application server, thus paying the price of heavy objects like repositories, services, crawlers, http clients, etc. I don't want to wait a lot of objects to be bootstrapped just to check if some code was executed on the controller, tests should be quick and clear to make developers love them as their programming assistant/guide.
DI is not the ultimate solution to use everywhere... Don't use DI just because you have it in your hands... In play, you don't need DI to develop controllers/models etc... but sometimes it could be a nice design: IMO, you could use it if you have a service with a well know interface but you would like to develop this service outside Play and test it outside play and even test your play project with just a dummy service in order NOT to depend on the full service implementation. Therefore DI can be interesting: you plug the service loosely in play. In fact, this is the original use case for DI afaik...
I just wrote a blog post about setting up a Play Framework application with Google Guice. http://geeks.aretotally.in/dependency-injection-with-play-framework-and-google-guice
I see some benefits, especially when a component of your application requires a different behavior based on a certain context or something like that. But I def believe people should be selective about what goes into a DI context.
It shows again that you should only use dependencies injection if you really have a benefit. If you have complex services it's useful, but in many cases it's not. Read the chapter about models in the play-documentation.
So to give you an example where you can use DI with play. Perhaps you must make a complex calculation, or you create a pdf with a report-engine. There I think DI can be useful, specially for testing. There I think the guice-module and spring-module are useful and can help you.
Niels
As of a year and some change later, Play 2.1 now has support for dependency injection in controllers. Here's their demo project using Spring 3, which lays it out pretty clearly.
Edit: here's another example using Guice and Scala, if that's your poison.
I am trying to understand Spring. I have read about it and done some tutorials. I kind of get the IoC paradigm and the fact that DI is its implementation in Spring.
My question is this: What do you lose by not using Spring? I understand this is a big question and somewhat subjective. But if you could write a few dot points or give an example of a problem that could occur if Spring was not used, I think that would help me and many other people.
Spring is far more than just another IoC tool (think of DAO related stuffs, convenient MVC support, testing tools, ...). In my opinion, it has gradually grown to a kind of "flavor" of Java. But that's not the point :)
Speaking of IoC/DI, what you loose not using it is the easiest way to gain loose coupling in your application, that is associated to reusability. Obviously, most of people tend to think of reusability of a component in another project, which, in my experience, occurs not that often. Greatest benefit of reusability appears when you have to unittest your code.
Programming through interface and using DI/IoC make unittests so easy that even those who are reluctant to unit test will start loving it.
Loose coupling and benefit in matter of UT is one thing you'll lose.
There are no problems actually. But if you start writing your code you will end up with a homegrown framework much like Spring. The thing you get with using Spring is that the framework is already more generic (than your own) and you can use it in a lot of different projects. And the most important (maybe) is that Spring is well tested with so many users using it.
Of course you can try also another framework not just Spring. There are a lots out there...
I did a write-up on why people use dependency injection frameworks (like Spring and Google Guice). Most tutorials neglect this, but IMHO it is the most important thing.
If you understand the problem you have, and what problems all these patterns/frameworks solve, only then are you able to make good software and great architectural choices.
Read about it here: http://www.redcode.nl/blog/2010/01/dependency-injection-dissection
Put simply, you apply dependency injection to write clean and testable code. Also in return you achieve a design in which the caller knows which implementation to use(inject) rather than callee (this is what's famous as the "Hollywood principle"). Now if you don't use use DI frameworks like Spring and Guice you try to achieve dependency injection using factories. But factories come with a cost of boilerplate code and uneasy clean-up while testing. Some people also find other strengths in these frameworks which is their easy integration with frameworks belonging to different tiers like Struts, Hibernate etcetera.
A glib answer is that you'd have to code it all yourself. I don't know much about Spring (yet), but even the basic act of constructor injection would require a lot of code whereas with Spring you need two edit points:
In config:
<sectionGroup name="spring">
<section name="context" type="Spring.Context.Support.ContextHandler, Spring.Core"/>
<section name="objects" type="Spring.Context.Support.DefaultSectionHandler, Spring.Core" />
</sectionGroup>
<spring>
<context>
<resource uri="config://spring/objects"/>
</context>
<objects xmlns="http://www.springframework.net">
<object name="mediaLibrary" type="AlbumLibraryWPF.AlbumLibrary, AlbumLibrary"/>
</objects>
</spring>
In code:
IApplicationContext ctx = ContextRegistry.GetContext();
library = (Library)ctx.GetObject("mediaLibrary");
Which would you rather do: write a DI framework yourself or concentrate of building your solution?
Spring is much more than a DI framework. There a lot of areas that it will make programming easier for you:
JDBC, Hibernate, JMS templates (dramatically reduce code line count)
Aspect programming
Security (Spring security)
Spring MVC
Spring Web Services
These are just some examples - there are many more. You don't have to use any of the above, but there all part of a mature, well designed framework and in general they make things easier.
The core of Spring is of course Dependency Injection. The benefits of using a DI framework may not be apparent for small projects, but there are more than evident for large and complicated ones. Martin Fowler explains Inversion of Control very clearly. Of course there other alternatives (Guice for example), but I would say that Spring is now an industry standard.
IoC is mostly a good thing within the Java language because when most applications start growing and you don't design for modularization/loose coupling, you end up with a big pile of interconnected classes without no sensible boundaries.
For starters, Spring and other IoC/DI frameworks makes you think about modularization right from the start. This is big because if you have your code well modularized/loose coupled, you end up componentizing and reusing much more wich leads to better unit testing (if you do unit testing anyway).
If I want to write a DAO, I can define its interface up front:
interface IPersonDao {
List<Person> getPersonsByTeam(String teamName);
}
then, I can just call for the implementation of this interface from anywhere in the src where's Spring is being "applied". Suppose i need it in a service layer:
class MyService {
#Autowired
IPersonDao svc;
}
or in a test class:
class TestPersonDao {
#Autowired
IPersonDao svc;
#Test
void testGetPersons(){
List<Person> persons = svc.getPersonsByTeam("billing");
Assert.assertDataSet(persons, "billing.xml");
}
}
Besides, my Dao implementation can hide the complexities of data access without messing with the Dao contract. If I require a hibernate session or a persistence manager, I just declare that:
class JpaPersonDao implements IPersonDao {
#PersistenceContext
EntityManager em;
List<Person> getPersonsByTeam(String tm) {
em.createQuery("...");
}
}
Componentization of classes requires a registry in order to wire collaborating beans. This could be developed by hand, but there are already DI frameworks that do this. Besides, Spring has alot of other stuff like exception translation, support for aspect programming, mvc frameworks, portlet frameworks, integration with hibernate, jpa and/or other db stacks which of course integrate nicely with the Spring IoC stuff.