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 7 years ago.
Improve this question
My system is connecting to Oracle through Hibernate/JDBC. I want to restructure it using abstraction to decouple its implementation from Hibernate library. That's a backup for someday the team can switch to another JPA implementation without painful to change core business logic to adapter with new JPA implementation. What are advices in doing this?
By the way, I want some advice from gurus what are common practices/tactics to decouple existing projects from external open source jars?
Direct dependence on standard and popular open source libraries is OK. You shouldn't consider it as a problem. For e.g I have a large code base and it depends upon joda-time, google-guava etc. Now, coming to your situation, following is my view point
There is very less chance that you move from one JPA implementation to another because by the time you get familiar with a particular implementation (yes implementation because you might want to optimize something or you are looking for some feature that is missing from standard JPA api) it would take some time and you really doesn't want to spend the same effort learning other implementation (business doesn't let you even if you want to ;-)).
Spring already abstracts most of the regularly used API's like JPA, JMS etc. so I suggest you look at that option.
You should program against interfaces to reduce dependencies. Your service classes -the ones that contain Business Logic- should depend on Data Access Object Interfaces instead of an specific DAO implementation. Something like this:
public class ImAServiceBean {
private EntityDAO entityDAO;
private void someBusinessLogic(){
entityDAO.createInstance(...);
Were the DAO interface goes this way:
public interface EntityDAO {
void createInstance (...);
void updateInstance(...);
Now you're using something like EntityHibernateDaoImpl, but if you want to change your persistence framework to MyBatis you can build an EntityMyBatisDaoImpl (which implements EntityDAO) and use that class in your Services classes with no change at all (asumming you're using some kind of dependency injection). The same thing if you use JPA, JDO or any persistance technology: your Business Logic only depends on a plain interface, and that interface can be implemented but any persistence technology, even JDBC
JPA already is a separate API. if your team uses JPA, then you should already have the ability to switch from hibernate with zero effort.
Related
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 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
What are the options to define the public interface to a library in Java.
For example I often find that things are public because another package in the library needs them (although still with a common base package, e.g. com.stackoverflow.mylib.), so they can't have the package access level, and generally people don't want massive packages (it also seems that people using Spring insist on having the separate controller/service/model/impl/etc. packages, resulting in a single "feature" being forced to span many packages, when say a given service might be a completely internal implementation detail not for external use...).
So the ideal goal is to make the Jar I provided to 3rd parties to make it clear that these things are not to be used, ideally by not having them available at all (not present in the API jar), so that it is not possible for them to use and compile with those internal objects/methods.
Even more ideally for objects there only supposed to obtain from some kind of factory (e.g. a provided Spring Bean), a way to prevent direct instantiation from their code or custom bean (which may leave some future, not yet present property uninitialised after upgrade).
The two formal ways I know of currently are:
In some projects I have worked on, there is an api package (e.g. com.stackoverflow.mylib.api), and the rule is only the contents of this package may be directly accessed by outside users.
In some other projects I have worked on, there have been some custom attributes, e.g. #PublicSDK to mark objects and methods for use by the public (and I think some extra stuff to ensure only things marked as such are in the publicly distributed javadoc and api jar).
The first thing to ask yourself is - do you really need to hide the implementation details?
The reason I say this is that there's going to be an expense involved in doing so, which depending on your circumstances may or may not be worth paying.
For example, if your API is being used by developers outside of your immediate team then it's probably worth the expense; however if it's just to hide the implementation details within you team I think it's overkill.
If the API is for use within your project then a standard where by you try to depend only on abstract types or interfaces is, imho, sufficient (and already the standard).
However, assuming you do need to hide the implementation and expose only the public API, the best way I know to do it is to produce two jars - one containing the public API and another that is the implementation of that API.
If you're using Maven or Gradle to build the project that is using your API you simply declare a compile time dependency on the API jar (artifact) and a runtime dependency on the implementation jar (artifact).
This pattern can be seen throughout the common Java APIs, the latest example being the JSON API that is implemented separately as part of Glassfish.
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 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 9 years ago.
Improve this question
I wants to develop service layer for my application using java. At the same time the service layer can also be exposed to webservice also.
My idea is to create one Generic Abstract Class for database operations , and all other service classes extend that abstract class and do the DB operation through that abstract class methods.
Is this a good idea to do it?
Please help me
It's hard to say with so few details, and without even knowing what you'll use to access the database (JDBC? JPA? Hibernate?). But
the service layer and the persistence layer are not the same thing. To ease decoupling and testability, I prefer having a pure service layer and a data access layer
inheritance is generally not the best way to reuse code. Use a well-design API, and prefer delegation over inheritance.
Also, don't reinvent the wheel. EJB3, Spring and other frameworks have good support to develop services and expose them as web services.
You should consider using some framework, which will help you with routine. E.g. Spring or Java EE. Those frameworks can offer you many built-in solutions like IoC, declarative transactions, declarative security etc.
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.