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
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 4 years ago.
Improve this question
I have been doing research on micro services. I have used spring boot seeing how simple it is to start with. During my research i have read that is a good approach that every micro service, that is the ones that do data access from a database, have its own database.
I am curious how this works when starting multiple instances of that same micro service. Can those instances of the same micro service work with just one database or they also need a separate database? The dilemma for me is the data would be different across multiple databases. How does load balancing micro services work for such situations?
edited after the first 3 comments
I appreciate the comments. I feel i was lacking in explaining my thoughts behind this question. I am used to building monolithic applications. I made use of spring and hibernate (hibernatedaosupport) and lately also hibernate envers. I use transaction management of spring to manage the commits and rollback situation of the database. This has worked for me so far. I have started looking into micro services and so far am unable to find a proper explanation of how spring transaction management used with hibernate and envers as a micro service would work with a single database. I can understand just one instance of this micro service working, but i am curious if multiple instances of this micro service would work properly with just one database. Especially considering the fact that hibernate would cache objects of the database for performance reasons, not to mention envers and its actions.
There is no requirement about that micro-service must have a different database, you could share one database across all your micro-services or have one per micro-service. It depends on you and architectural decisions taking into account the different tradeoffs.
If you decide one database per micro-service and you have many instances of the same micro-service. You must use just one database (like with monolith). About your concerns of Hibernate and Cache you must handle the cache in different way, by example using Hazelcast (https://hazelcast.com/use-cases/caching/hibernate-second-level-cache/) or EhCache.
Anyway the design patterns are just best practices with different tradeoffs, you must understand the advantages and disadvantages of every pattern for later take a decision.
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
My team is working on a medium size application (OLTP style). We were interested by switching to JPA instead of only using JDBC queries. Mostly for performance and practical reason. I'm not looking for a tutorial that shows me how to create a persistence.xml or Entity class in Eclipse. What i would like to know is what would be the steps to convert all the database queries into the JPA format. I know that the whole application must use JPA.
Many programmers has worked on this project over the years, so not everyone has the same SQL knowledge or the same programming skills. So there must be in this application 1000+ customs queries, using multiple tables (something that native JPA does not support very well), or query that is selecting only a few fields in a table... This is getting a bit out of control and i think that JPA would create a nice toolbox to make sure that everyone is going the same direction.
What should i look for to make sure that i'm not going into a process (convertion) that will never end ? Some sort of guideline.
(Again, i'm not looking for programming exemples, nor Eclipse tutorial.)
Thanks!
First step is convert you database schema into database model using JPA, you need to be clear what are the table, sequences, database objects that you are using in your existing application and start modeling all the schema with JPA you should consider use JPA annotation.
The step above will determine what will be your entities, embeddables and mapped superclass, their properties and the relationships they have, this step is very crucial as your logic will depends on the correctness of this model.
Then start looking for all the queries that are involved in your project, as you said that you have 1000+ queries consider use two scenario, convert all of them in JPQL queries or use a mix between native queries and named queries, I really prefer to convert all in JPQL unless are very database dependent. A step you must follow is find all of them, probably are some existing tool that convert from SQL to JPQL but I believe is better idea make by your own.
Once you have queries and model for the database start the creation of your new DAO using JPA and EntityManager stuff, I should recommend extract the interface for your exisiting DAO and start moving to a JPA implementation using the same interface, this will avoid break some code on your own, don't forget unit and IT test for your new DAO.
Also with the above approach you could start moving the application module by module, DAO or by DAO does not require to move full application at once. This will give you a kind of process in which you will see some progress each time you finish a new DAO or module.
Not sure what you mean about programming examples, I think those are the required steps but each project is different from each other, so consider this as some kind of guidelines.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
Questions asking us to recommend or find a tool, library or favorite off-site resource are off-topic for Stack Overflow as they tend to attract opinionated answers and spam. Instead, describe the problem and what has been done so far to solve it.
Closed 9 years ago.
Improve this question
As I had written in title, I am trying to learn Spring 3.0 (I already know Django, Pylons and few simpler MVC frameworks) and try to use Cassandra as a backend for my web application.
Are there any real world examples of doing this? Or maybe some tutorials? I know about the existence of documentation of both technologies, yet I am looking for something "faster" to read and get me rolling.
I'm the author of Hector https://github.com/rantav/hector, the leading java client for cassandra so I would encourage you to have a look at what it has to offer.
While I personally have not been using hector with spring, we did get a few contributions which added spring support. See for example https://github.com/rantav/hector/blob/master/core/src/test/resources/cassandra-context-test-v2.xml and https://github.com/rantav/hector/blob/master/core/src/test/resources/cassandra-context-test-v2-new.xml
If you are already familiar with MVC frameworks then you should be aware that which database/datastore you use in the backend shouldn't impact your MVC application as a whole, or how you structure things - it should only affect your data layer and how it retrieves data.
With Spring MVC, the accepted practice is that you represent your data model as a series of "domain model / classes", which are typically just POJOs to hold your data. "Domain" here means that it is related to your problem domain; so if you have an application which deals with customers ordering things you'd want to have a Customer class, an Order class, etc.
Each of the three layers of your MVC application - the controllers, the service/business logic layer, and the DAO layer interacts with these domain model classes. Since the DAO layer is responsible for retrieving or updating this data in the backend, this means it is the DAO layer which needs to know how to fetch your Customer or Order class from Cassandra, how to update certain Customer fields, etc.
So there is nothing special about how you would build your Spring MVC application itself when using Cassandra or any other "NoSQL" database. You'll just need to provide different implementations of your DAO classes which can communicate with Cassandra.
If you are asking if there are any pre-built Spring utilities that can access Cassandra (or Thrift) then the answer is no, at least as far as what's in Spring 3.0. But this should be pretty simple to write once you have the DAO interface set and all other layers of your application in place.
AFAIK there is no "public" tutorial or example covering Spring (3.0) in conjunction with Cassandra.
So maybe you could look into it :)
I would recommend to start looking at the "template" terminology in Spring (e.g JDBCTemplate and HibernateTemplate) and create something like a "CassandraTemplate".
I don't think there is any cassandra-spring library available. However, you could use Spring to instantiate and configure the bean that talks to Cassandra, and inject that into any other bean you have that requires persistence. That way you can let it benefit from Inversion Of Control and all the facilities the Spring ApplicationContext offers.
That way you can separate the code that is aware of the cassandra datastore from your business logic and use spring.
So, your component that talks to Cassandra will be of the [#Repository][1] stereotype, e.g. it is a Repository, just like a repository that talks, for instance to a JDBC datasource.
I am involved with a project using Spring with Cassandra called Easy Cassandra. A sample is provided here:
https://weblogs.java.net/blog/otaviojava/archive/2013/08/25/run-cassandra-spring-data
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 5 years ago.
Improve this question
I have an existing J2EE enterprise application to which I need to add auditing, i.e. be able to record CRUD operations on several important domain types (Employee, AdministratorRights, etc.).
The application has a standard n-tier architecture:
Web interface
Business operations encapsulated within a mixture of stateless session beans and transactional POJOs (using Spring)
persistence is a mixture of direct JDBC (from within the business layer) and EJB 2.x BMP entity beans (I know, I know)
My question is: are there any standard patterns or (better still) frameworks/libraries specifically for adding auditing as a cross-cutting concern? I know AOP can be used to implement cross-cutting concerns in general; I want to know if there's something specifically aimed at auditing.
Maybe you should have a look at Audit4j that provides auditing of business functionality and has several options for configuration.
Another framework is JaVers that focues more on auditing low-level modification on persistence layer, which might match your case a bit better.
Both framework provide audit-specific functionalities that goes beyond plain AOP/Interceptors.
Right now I'm leaning towards using Spring AOP (using the "#AspectJ" style) to advise the business operations that are exposed to the web layer.
I'm going to go a bit against the grain here and suggest that you look at a lower-tier solution. We have a similar architecture in our application, and for our auditing we've gone with database-level audit triggers that track operations within the RDBMS. This can be done as fine- or coarse-grained as you like, you just have to identify the entities you'd like to track.
Now, this isn't an ideologically pure solution; it involves putting logic in the database that is arguably supposed to remain in the business tier, and I can't deny that this view has value, but in our case we have many independent application interacting with the data model, some written in C, some scripted, and others J2EE apps, and all of them have to be audited consistently.
There's possibly still some AOP work to be done here on the J2EE side, mind you; any method that updates the database at all may have to have some additional work done to tell the database which user is doing the work. We use database session variables to do this, but there are other solutions, of course.
Try an Aspect Oriented programming framework.
From Wikipedia "Aspect-oriented programming (AOP) is a programming paradigm that increases modularity by allowing the separation of cross-cutting concerns".
For all EJBs you can use EJB 3.0 Interceptors (This is something similar to Servlet filter) and another similar interceptor for Spring (not familiar with spring)
As you are using EJBs as well as Spring that may not cover the whole transactions. Another approach could be using a Front Controller however that requires some modification in the client side. Yet another approach could be using a Servlet Filter however that means implementing the domain logic in the presentation layer.
I would recommend the Front Controller in this case.
I've just learned about a new Spring project called Spring Data JPA that offers an AOP-based auditing feature. It's not GA yet, but it bears keeping an eye on.