Nowadays typical JAVA application can expose some JPA entities via REST easily. In that case in short there is e.g. persistence.xml where driver, database, etc are defined to access the database and persistence unit easily can be used in the application.
I am looking for something opposite. I.e. if somebody saw the solution where persistence relays on REST API?
Background of my question is the following.
There is an app written in some ancient technology and there is quite complex logic behind. I would like to build new JEE JPA (Eclipselink if possible) based application which could (at least for some time) use that complex logic in order to find and read data. My idea was to implement REST interface on top of old application and let the new one use REST queries in order to deal with the data. Since logic is complex I would like to avoid duplicating it and maintaining 2 branches of code in different technologies until I am fully prepared to move all stuff into modern technology.
Do you think it is possible?
You can design your Data Access Layer and the rest of your new application so that it doesn't care how the data is stored (no "bad" dependencies).
You would then need to create separate versions of the DAL, where one would fetch the data from the legacy REST app and one would use JPA. This will make it possible to start out being dependent on the legacy app, and part by part build the JPA DAL to retrieve data from a database.
Related
I have an application with a huge code base which uses an Oracle database. I want to develop an hibernate app which can interact with incoming and outgoing request from the above said application without any dependencies of database.
Like if I want to change the database to mysql or postgresql it would not have any problem. Is this practical? Can it be done? Asking for help.
As to practicality, very seldom does an app ever change databases. While the idea sounds great it isn't often done and generally the benefits you can get from using built in database features sometimes outweighs the work of keeping it database independent.
As to it being done, it certainly can between SQL databases. To go from SQL to noSQL is a bit more tricky as they are in the process of supporting them in JPA. If interested in that take a look at Hibernate OGM. If you want to truly keep it so you can easily switch databases you need to stick to the JPA standard. See this on generating JPA compliant entities from the database. So long as you use ONLY JPA you can easily switch between the databases that provide a JPA implementation. Then you just include the correct implementation set the dialect and you are switched.
If you have access to change the current application it will probably be easier to just update each of the actions that contain the hard coded queries with your JPA code. If you have unit testing that would make this process much easier as well.
If you want to write something new, but not change the front end, you would need to handle whatever actions your forms on the front end are submitting. Making sure to make them available at the same path and with the same HTTP methods (GET, POST, PUT, etc.), that take the same parameters, and returning the same structure as what your actions due today.
Both approaches would allow you to go action by action replacing them. With writing something new though, replacing them one at a time is a little more difficult if both the new app and old app aren't in the same domain OR if authentication/authorization is involved.
Good luck and best wishes!
I have built a proof of concept for a webapp I've been working on for the last year. My app already has a well defined set of operations that are reused by the business to interact with orientDB. The interactions start from simple insert/queries to objects, to complex object inheritance creation, and new relationship types creation.
Right now I'm moving my POC Architecture to a formal model, and I want to migrate what I did using only the orientDB java API, to a more formal JPA model; So far I have checked the code and examples for spring-data-orientdb and spring-data-gremlin, which seems to provide a JPA approach. My question is the following; If my model has no more than 5 queries, does it make sense to add the JPA model? and also, from this jpa model, can I still have transactionality for direct db operations like new type of vertex creation among data insertions? has anybody has experienced the use of this API, their pros an cons?
I understand that both are still in dev (Is Spring Data OrientDB production-ready?) but want to know if anyone has any advice on where to move forward, or if it's better to wait until the projects are mature and keep working with document/graph API?
I have an existing web forms project which consists of 3 different projects: UI layer (Web project), Business Logic Layer and Database Project. I have already written the data access methods which connect to the database and return data to the business logic layer.
Now we need to provide a REST API, and I was thinking of using oData API along with REST. But all the examples I have seen use Entity Framework and I just cannot use Entity Framework because our data access layer returns data to the business layer, which then processes that data and adds some logic, and then present it to the UI layer.
Can I still use oData API? If yes, then will I need to create fresh methods manually for each of the complex query of oData API? How will OData API access my BL Layer?
You can do this (I have just done similar myself) but it is very hard work.
To me, OData always felt like a way of exposing the entity framework through web services so if you were to try and implement it without the entity framework you will end up spending a lot of time parsing queries to your data access layer.
If you do decide to go down this route, maybe consider only implementing part of the OData spec - work out which parts you actually want to be able to use - as it is huge and the task is daunting.
These are only from my experiences though and you may have a better data access layer API setup than I had when I started which could make things significantly easier.
EDIT to answer last question:
Will you need to create fresh methods manually for each of the complex query of oData API? This will really depend on how your data will be exposed and how your data access layer is setup.
I'm starting a new Java Web project using Spring and obviously I need data access in my application.
In previous applications I used JDBC or ORM modules of Spring framework to implement my data access layer, but some times ago I read about Spring Data project. I'm curious about it and I'd like to know the diffenrences between the two projects and understand if there are advantages passing from one approach to the other.
Spring data provides several functionalities:
Common functionality related to database applications - Defining a "repository" element (similar to DAO) with various functionalities, audit trail, etc.
JdbcTemplate like support for various NoSQL databases - MongoDB, Redis, Neo4J, and there are several community projects for other databases
High level functionality for JDBC (mostly Oracle) and JPA to reduce boilerplate code
Spring data also aims to save boilerplate code, as the repositories are defined as interfaces and the implementation is given by spring based on the method names.
Spring Data use JPA. it is also great for reducing the amount of boilerplate code that you need to write.
By writing the interfaces
E.g. table.findAll()
Its uses aspects to create the boilerplate code to select * from table
or table.findByName
it will implement the code to select by Name
have a look at this excellent tutorial http://www.petrikainulainen.net/spring-data-jpa-tutorial/
We have a large offline process that updates the model I designed inside of Play Framework. I think it makes sense to keep this code as a stand-alone project -- but I would like it to be able to use the JPA Model designed inside Play.
I'm wondering if there's a good way to handle this -- a way to reference the JPA Model independently of Play Framework (inside another vanilla Java project).
Another option is to create an API that the external process calls, which is what I've done so far, but it introduces a lot of unnecessary network latency.
Any pointers on how to accomplish this?
Passing around a Play specific JPA entity (ie. that extends Model) is probably not a good idea. You'd be introducing a dependency on the Play jars where they are not required.
As I see it you have two viable options:
Create the object as a POJO and use a Hibernate Xml Config (for Play
versions less than 2.0) to define the mapping to the database. You
can keep the pojo and the config entirely separate - ie. keep the
config in the classpath of your Play App.
Pass your object around in a serialized form eg. XML or JSON.