Tag Info

Hot answers tagged

32

What does the Spring framework do? Should I use it? Why or why not? Spring is a framework that helps you to "wire" different components together. It is most useful in cases where you have a lot of components and you might decide to combine them in different ways, or wish to make it easy to swap out one component for another depending on different ...


25

First, what is dependency injection? Simple. You have a class, it has a private field (set to null) and you declare a public setter that provides the value for that field. In other words, the dependency of the class (the field) is being injected by an external class (via the setter). That's it. Nothing magical. Second, Spring can be used without XML (or ...


24

Since other posts here mention the upside, I'll mention the negative aspects of Spring. Even with these negatives, Spring is omnipresent in its niche, reliable, and works as advertised. So, on to the negatives: Enormous: I wouldn't like to put jars with 3000 classes into my little hobby project. There are some descriptions of it as slower than some other ...


11

For earlier versions of both the frameworks book authors were saying that if we keep configuration in xml files then it will be easier to maintain (due to decoupling) and just by changing the xml file we can re-configure the application. Back then annotations didn't exist. People hated the XML files, and Java got a horrible reputation because of them. ...


10

First of all, your understanding of dependency injection is not fundamentally wrong, but quite different from what most people mean when they use the term. What you describe is a rather strange and unconventional way to achieve testability. I'd advise you to move away from it, as other developers will be rather puzzled by that kind of code. Dependency ...


9

I would suggest doing neither. Trying to enforce a technical layering with a package structure leads to a lot of entanglement in your application. Not to mention the fact that we try so hard to hide everything behind a service interface and the first thing we do (mostly due to packaging) is make everything a 'public class'. This becomes painful when there ...


8

There are very few downsides to Spring I thought long and hard in order to find any serious downsides to using Spring, and I'm afraid I've failed. Spring is an excellent toolkit within the JEE/OSGi models. It provides a wide range of non-invasive templates that greatly simplify working with the often cumbersome supporting APIs provided by application ...


8

The EJB 3+ frameworks are actually pretty good as they came along with JPA as an answer for annotation configured Persistence frameworks, as well as CDI which allows for annotation configured dependency injection. You also add on top of that Weld. Spring on the other hand is just now catching up in the game with configuration through annotation. With that ...


8

An architecture is the the abstract design concept of an application. Basically, a structure of the moving parts and how they're connected. A framework is a pre-built general or special purpose architecture that's designed to be extended. If an architecture is the design of a structure, a framework is the architecture of a foundation. Frameworks are ...


8

Many of the Gang of Four Design Patterns are really just workarounds in Object Oriented languages for mechanisms that are already available in Functional languages. Consequently, the best languages for design patterns (from a productivity standpoint) are the ones that don't require them. If you don't need the pattern, then you don't have to spend any time ...


7

The Maven file structure may help with this In essence the Spring configuration files (that can have any name by the way, not just the generic applicationContext.xml) are treated as classpath resources and filed under src/main/resources. During the build process, these are then copied into the WEB-INF/classes directory which is the normal place for these ...


6

Well, the key here is familiarity. IMHO, the only way to achieve familiarity is by practice- use Spring, Hibernate, etc. and you will increase your knowledge about them. One of the strengths of the Java ecosystem is the great number of libraries/frameworks which come with great documentation- Spring's reference manual is excellent and reading it will teach ...


6

You need to try to understand the software from an architectural perspective. That's going to be hard to do studying stack traces. I would start by laying out the classes in a UML diagram. Struts is an MVC framework, so the project is probably an MVC one. Find out what all of the frameworks are, and analyze your class layout to determine the role each ...


6

I would say that just by reading your analysis, you're saying there are alot of static methods and singletons. Static methods shouldn't be an issue by themselves, but if they're being used to proxy calls to the singleton objects, I would work on making those either rock solid, or replacing them with a more sane object model. Static methods are useful for ...


6

You're right, Spring is inappropriate for the use case you listed. Spring is better used for managing external dependencies (like plugging a JDBC connection into a DAO) or configurations (like specifying which database type to use). In your example, if the bean type was liable to change, then you'd use an interface to specify the bean, and instantiate the ...


6

Not at all. In my opinion, if used sparingly, it's actually one of the most useful patterns you'll find. It's an easy way to solve otherwise extremely difficult problems. Sure, every criticism is true, but to be honest, I'm willing to deal with a little bit of a bad pattern in an otherwise well designed application / framework that follows the other, better ...


6

At jClarity we've definitely followed this approach. We have a 'pure' HTML5 front end - AngularJS, HTML, CSS and a host of Javascript micro frameworks which is a separate project to the backend - vert.x with a variety of verticles coded in separate JVM languages as appropriate. The trick is to have a well defined messaging API between the two that is tested ...


5

For why do you want to use Spring, You can read it on http://www.wrox.com/WileyCDA/Section/Why-Use-the-Spring-Framework-.id-130098.html In summary : J2EE applications tend to contain excessive amounts of "plumbing" code. Many code reviews repeatedly reveal a high proportion of code that doesn't do anything: JNDI lookup code, Transfer Objects, ...


5

You probably should have unit tests and integration tests. In the unit tests, you test for example your controllers/services in isolation. To achieve that, you may use for example a mocking framework such as Easymock or Mockito to cut the dependency to the database. Your integration tests should go the whole way, from your controllers/services right to the ...


5

I'd use Spring (or another DI system) between layers, direct instantiation within layers. So a class that creates a bean that leaves the scope of that class, to some (functionally) external system, possibly defined by that system or some communications layer, would be created through DI. Another bean created purely for internal use within the application ...


5

Spring aims to provide you a framework where there is "convention over configuration". However the reality is that Spring applications do need a certain amount of configuration. In the Spring 2.5.x and earlier versions, the common idiom was to provide this configuration via XML. With Spring 3.0+, the idiomatic way is to use annotations (something that Java ...


4

From a day to day coding perspective the biggest difference I noticed was that in academia I never had to work with legacy code, and any code I wrote was probably never going to be maintained by anyone else for very long. It took year or two of working in industry to realise the importance of writing maintainable code - agile methodologies such as ...


4

It's certainly not idiomatic in Java, C# or most any OO language to have a lot of static methods that make assumptions about the state of the universe (typically indicated by use of static variables). I've experienced the pain of untangling at least two large-scale applications and one integration test project that introduced static variables everywhere, ...


4

When you use setter-based dependency injection, the init-method makes it possible to perform initialization: the specified method will be called after all the setters have been called. As per destroy-method, it seems that implementing finalize in Java classes is not a good practice, instead, and many libraries define a close method which may or may not be ...


4

Many of the Spring annotations are now standardized (e.g. CDI for dependency injection), so you're not at all tying yourself to Spring by using them. And for those that aren't: your application won't work without the functionality, will it? So it's basically tied to Spring, whether or not you try to hide that fact. Annotations are much better for ...


4

I find it useful to implement a Service Facade that decouples the implementation of services from the service contract. The Controller from the presentation tier (your MVC stuff) should be able to make a single call to a Service Facade, which then orchestrates the calls to one or more "service" objects/methods, and returns whatever the service contract says ...


4

First of all, transaction management should be done on service layer, not on DAO layer as that would create a lot of performance overhead (to deal with appropriate transaction isolation level and propagation at each different method). Also, the scope of a unit of work comes from the service layer instead of the data access layer: imagine performing a ...


4

If you've got a good grasp of HTML, CSS, and JavaScript, you have a leg up on many people who end up doing web development. The concepts behind JSP are very similar to PHP. The quirks are different. A servlet is the name for a chunk of Java code that serves a request. That's it really. The whole original Struts framework was a single servlet. I would ...


4

It should be in a Service Layer. public interface UserService { public void findByLogin(final String userName); } And in a Service implementation : public class UserServiceImpl implements UserService { @Inject private UserRepository userRepository; public User findByLogin(final String userName, final String password) { ...


4

First, I would suggest that you package those two independently, and just offer proper documentation as to what the purpose of each library is. It will give you more flexibility in the long run, as you might have to bypass the Service layer at some point or use the Data layer as a common-functionality library for other projects. That being said, I agree ...



Only top voted, non community-wiki answers of a minimum length are eligible