We’re rewarding the question askers & reputations are being recalculated! Read more.

Hot answers tagged

87

Sandi Metz, a renowned software engineer and author in the Ruby ecosystem, has a great blog post and a talk where she also talks about the relationship between duplication and abstraction. She comes to the following conclusion duplication is far cheaper than the wrong abstraction And I completely agree with her. Let me give you more context to this quote....


70

Duplication can be the right thing to do, but not for this reason. Saying "we might want these three places in the code base to behave different even though right now, they're identical" is not a good reason for large-scale duplication. This notion could apply to every system, and it could be used to justify any duplication, which is obviously not ...


37

Whenever a developer asks "what's the point of doing this?", what they really mean is "I see no use case where doing this provides a benefit". To that end, let me show you a few examples. All examples will be based on this simple data model: A Person entity has five properties: Id, FirstName, LastName, Age, CityId And you can assume that the application ...


34

If people start reasoning about design with the words "if tomorrow", this is often a big warning sign for me, especially when the argument is used to justify a decision which includes extra work and effort, for which noone really knows if this will ever pay off, and which is harder to change or revert than the opposite decision. Duplication of code reduces ...


28

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


26

We don't need the frameworks. It is entirely possible to implement dependency injection manually, even for a relatively large project. On the other hand, using a framework makes it easier, particularly one based on annotations or automatic detection of dependencies, as it makes the process simpler: if I decide that I need a new dependency in a class, all I ...


25

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


18

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


17

Here is one of my favorite kick-off examples of structure for your spring rest app. 1. Separation of layers, each layer is an individual module/project REST API Packaged as war (Could be jar if you are using spring boot with embedded server. Spring boot doc clearly explains how to deploy the so-call uber jar. It is deadly simple.) It has rest ...


16

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


14

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


14

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


13

In addition to the answers above, what ever you do, please don't just go and learn the framework!! Hibernate is the most popular implementation of the Java Persistence Architecture (JPA) standard. However, it is not the only one and so understanding JPA before tackling Hibernate is recommended. With Hibernate, learn how it works under the hood so that you ...


13

What does the Spring framework do? Spring is as today not only, what was known as a simple framework, it is a complete ecosystem. Topics covered by the spring ecosystem: Spring Framework (e.g. Dependency Injection, AOP ...) Spring Cloud Spring Data Spring Security Spring Batch Spring Social See here for full coverage of the ecosystem. It is possible to ...


13

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


13

No, you should not wrap DAO exceptions in a web application It's a lot of noise in the code for zero benefit. DAO exceptions are unchecked exceptions for a good reason. The application code cannot do anything useful to recover from a DAO exception. The real problem is here: ... it'll be caught by a JSP showing an error message to the end user. Fix this ...


13

Duplication to prevent coupling. Let's say that you have two big systems and you force them to use the same library. You may be coupling the release cycle of both systems. This may not be too bad but let's say that one system needs to introduce a change. The other needs to analyze the change and may be affected. Sometimes it may break things. Even if both ...


13

Your new architecture is also not derive from Domain Driven Design. Of course in context of tactical patterns (as strategy patterns scope go beyond the code). In Domain Driven Design you have plenty useful building blocks which can help you with managing accidental complexity of your system. But before you start tot apply them you need to answer very ...


12

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


12

Why do we need DI (Dependency Injection) at all? The DI mechanism separates object production from object consumption. The dependecies an object needs are delivered transparently from the outside. The advantage of the mechanism is clear: You could anytime swap out dependencies, e.g. usìng a Null Object for testing purposes. How is it done? There are ...


12

If you did go for microservices to benefit from scalability, loose coupling, and easy independent modification of each service, the you should stick to it to the maximum possible extent. Overall architecture I think that the best approach would be: have a microservice for general user information management; keep microservice specific user ...


11

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


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


10

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


10

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


9

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


9

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


9

Repeat after me: REST and asynchronous events are not alternatives. They're completely orthogonal. You can have one, or the other, or both, or neither. They're entirely different tools for entirely different problem domains. In fact, general purpose request-response communication is absolutely capable of being asynchronous, event-driven, and fault ...


9

It would be wasteful to always fetch the entire objects. First I would question this. If your objects are well-designed and not too bloated, the performance and memory overhead of fetching them completely instead of getting them partially is often negligible for most real-world cases. The performance of SQL queries over a network are way more dependend on ...


8

Agree with @ericW's comment, and just want to add remember you can use initializers to keep your code compact: @Autowired private Converter converter; or private Converter converter = new Converter(); or, if the class really has no state at all private static final Converter CONVERTER = new Converter(); One of the key criteria for whether Spring should ...


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