Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 4 years ago.
Improve this question
In our team we're having a bit of a discussion while developing a fairly straightforward Spring Boot app. Because we wanted to clearly separate concerns, we have modularized (Maven modules) our system into three modules:
Service: has the Spring Boot dependency, depends on Model & Repository
Model: only has the domain classes and 'service' classes (no Spring Boot dependency)
Repository: only has the JDBC access logic (depends on Model, no Spring Boot dependency)
I've done a few Spring Boot projects before and this is the first time I've set it up like this. I have particular concerns as to whether it makes sense to keep Spring Boot out of Repository because it will require us to do a lot of the wiring, like JDBC, jooq, liquibase, etc. manually in Service.
Has anyone got any advice about whether or not it makes sense to do it like this?
I think that this question might have opinion based answers. However... I think that this separation can lead to a development model that looks more like the old waterfall model rather than modern approaches. As microservices approaches teach, I think that it could be better to apply a vertical separation of concerns, modularizing the application in functional areas and not by abstraction level. Internally, each module should handle everything is related to its functional area.
I have particular concerns as to whether it makes sense to keep Spring Boot out of Repository because it will require us to do a lot of the wiring, like JDBC, jooq, liquibase, etc. manually in Service.
If you use correctly TDD frameworks this should not be an issue. I already work on multi-module Maven projects (Spring Boot) and I have never had issues about this, but obviously it depends on what you are doing in your projects.
Related
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 2 years ago.
Improve this question
I am creating javafx desktop application and javaee application. They will be almost same in functionality. Both applications needs to have its own sql database, but the databases will have same structure (same tables).
I am using Eclipse IDE and what i have done so far is this:
One project for javafx application
One project for javaee application
One project for data layer (jpa)
I am also using module-info.java. For javafx and javaee project i have defined required package to be my data layer project.
I have found here: JPA and EJB - When do I need to use transaction?, that i should use transactions when working with Java SE, which my javafx app actually is, but not when my application is javaee. I do not want to write jpa project for each application. How to create/set up projects properly, so that each of my applications will have separate, but same database?
Have the common code in a separate code repository, release it and add a dependency to this module in both applications. Use Flyway or Liquibase in the common code to manage the database schema.
Consider to use Spring Boot instead of Java EE.
Spring, as Java EE, supports declarative transactions (see Spring Data), but Spring is more easy to use with Java SE. AFAIK it's possible to combine JavaFX applications with Spring. This would allow you to use declarative transactions in your JavaFX application as well. This would make it easier to share code between backend and frontend.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 2 years ago.
Improve this question
I recently started reading a book that explains in more detail the manipulation of databases, in terms of the relationships between them, especially. The problem is that this book is a bit old, from 2014. So I come with the following questions, to which you can clarify, please:
In the book we use Dao, Dto and Service pattern, but we can't use JPA, Spring Boot Repository or other new technologies to "replace" the old implementation that the book presents?
If so, can you give me an alternative to the code below, and how does it work? What could I improve, what could I give up, what should be completed, what should I learn, please!
Book divide the implementations of an Application in 2 teams:
UserInterface (Data Transfer Object of the entity, singleton in Memory DB and Controller as Mock Service and view)
Development Team (with creating the Entity and testing using TDD, creating DAO for that Entity, Business Service Tier and Presentation Tier
So, I can change this way of creating and manipulating the applications and Databases, if yes, how, and why? What should I use, how should I do it?
This is the git of the book I'm currently reading: https://github.com/Spring-Hibernate-Book/spring-hibernate-datamodeling-tdd-rest/tree/master/Spring-OODD/src
As far as division of labor, the concept of having a separate team work on the controller layer seems antiquated. It could be that the single-page-UI has its own team, but many places prefer that the same people work on everything for a feature front to back, in order to reduce opportunities for communication problems between teams.
The extent to which you need DTOs should be up to the developer's discretion. It used to be a practice to routinely copy all entities into DTOs to avoid issues like lazy-loading in the UI. If you are building a single-page application where you're passing JSON to the UI that isn't an issue. The single-page application architecture provides better separation between UI concerns, making DTOs less necessary in most cases.
For the rest of this the concepts should map over. A Spring JPA repository has the same function as a data access object, it just provides more of the implementation for you. The biggest change associated with the Hibernate mappings is to use JPA annotations instead. Services haven’t changed.
TLDR
things that have changed:
single-page applications have replaced serverside approaches like JSPs
standardizing on JPA instead of Hibernate
configuration classes, no application context XML anymore
profiles
focus on microservices vs. monoliths
more batteries-included (h2 by default, deployable jars, convention over config)
things that haven't changed:
general layering scheme of controllers calling services calling data access
Hibernate mapping strategies and general ORM issues
Spring transaction support
general Spring programming model with beans, DI, AOP
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 4 years ago.
Improve this question
I am getting task(for learning new technologies) to create a facebook like project with
1. Auth (Spring Boot,Spring security, MySQL, ember.js)
2. Messaging (Spring Boot, Kafka,Cassandra, ember.js)
3. Member (Spring Boot, ember.js)
4. Reporting (Kafka, Spark, ember.js)
functional.
I need to get help for project structure. Should I have four separated modules (like auth, message, member, report) + core module. And what I should put in core module(entity beans, helpers, utils...)?
Thanks in advance.
Keeping code organized on huge projects is important, making each functionality into it's own module is desired.
But only if you are experienced enough should you begin with that. It might be better to start off in one module and expand later into separate modules.
In the core you construct tests that determine if the application as a whole is functional, etc. Core could also include the REST for everything else than the modules you already said.
Or do you plan to make the front with react?
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
I have used hibernate in my java project where I have used Spring MVC.
I avoided SPRING HIBERNATE because it seemed that it was making my code very tightly coupled. Now, even if I move the app to struts, my service layer would work fine (because I have used the core hibernate , it is not the one that spring provides).
I would like some experienced developer to answer this:
What is the reason of using spring hibernate? I know it provides a number of features but there is a trade off as it really makes your code tightly coupled, you can't re-use the services any where else since they would work based on spring's hibernate api
Spring having 7 different modules each are independent you can use anyone of them or multiple
The core container
Spring context
Spring AOP
Spring DAO
Spring ORM
Spring Web module
Spring MVC framework
you want to know about the ORM integration believe me it doesn't make any tight coupling with your service layer
you can use strut mvc at the same time on service layer spring-orm + hibernate there is no tight coupling, more over spring is providing transaction mgt. hibernatetemplate support, you need not to take care of session and transaction mgt and of course easy integration and configuration.
According to my experience Spring-Hibernate provides:
A template to make 'easy' its configuration
The persistence engine can be used as a dependency, so you can change it whenever you want without modify JPA annotations in your model classes
It's supposed to be much more efficient managing XA transactions
And nothing else ...
well complex question, i could answer it with another question :
What is the reason of using hibernate? I know it provides a number of features but there is a trade off as it really makes your code tightly couple, you can't re-use the services any where else since they would work based on hibernate api.
Why not using direct JDBC and SQL ?
To be more productive on the question : choosing a framework always come with a trade off : being coupled with the framework.
So either the features provided by the framework be worth to pay the trade off or not.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
I have worked on struts 1.2 and DWR as front end MVC framework.Now i have two projects to develop one is simple web application and another is complex.Which one i should select from most prevalent MVC Framework Spring mvc, Struts 2, DWR,JSF and brief reason to select any of the MVC . Most of the team knows all the frameworks. What are the factors i should consider to select any Framework.
I would consider what is the scope of my project, if I am anticipating complex system with lots and lots of various implementations, then I would go for Spring, for moderately complex system I would go for JSF.
One also need to consider if the primary designer leaves the team would other team members or a new comer will be able to pick particular MVC framework with ease or not (consider using well known MVC vs not-so-well-known-personal-favourite-picked-out-of-google). How mature the particular MVC framework is, are there good books written about it etc. These are just from top of my head.
Also keep in mind when there is too much of Spring (or any other ioC container) involved, there comes a time (after 8-12 months) when you are unable to debug code correctly because there are so many classes involved that you just keep tracking which class goes to which spring context files etc.
Finally, as one of my mentors used to say, don't solve the world problems (by using lots of design patterns), solve the problem at hand. :-)