Tag Info

Hot answers tagged

47

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 ...


37

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 ...


29

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 ...


13

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 ...


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

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 ...


9

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, ...


9

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 ...


9

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 ...


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

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

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 ...


8

In its broadest sense, a "transaction" is a group of actions that should be performed as if they were a single "bulk" action. The term is most often used in the context of databases, but it can be applied to many kinds of programs (particularly ones that implement a command pattern). When we're talking about databases, and often even if we aren't, we want ...


7

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

Used to be we wrote simple, efficient, fast applications and web services using just core Java, Servlets and JSP, html and xml, JDBC API. It was good enough; JUnit was a good tool to test. We rested easy that our code worked. Hibernate came along to simplify SQL and enable true mapping of Database tables with Java objects, allowing hierarchical ...


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

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

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

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 ...


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

I don't think that article is implying that every method should should be logged that way, it's just saying when you're logging make sure you capture the context in which the log occurred. For example, if you have a log which says only "User cannot be found", if you're actually trying to understand the scenario which lead to that log then you probably need ...


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

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 ...


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

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) { ...


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 ...


5

Anything you put into the Spring XML is static and compiled into the binary. If there is some information which can change, it is always a good idea to externalize it into a properties file. Spring can read the properties file and then use the values as inputs to its beans. You need to use a concept called the property placeholder to inject these ...


5

I think an important factor is who your service clients are. If your service layer is just an architectural boundary between layers in your own project, and the service client is within the same trust realm, then its ok to relax things, and let unchecked exceptions bubble out to the controller layer, or the service client. However, for public facing code; ...


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 ...



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