We started writing a Java Framework for our company. But we don't have enough experience about Java. We decided to use JPA framework for database CRUD operations.
What do you suggest about that:
about defining persistence.xml. We search creating dynamic
EntityManager and found some documents but we don't know that is
it best way.
Is it a good way that create a layer over JPA base db operations?
(for example CRUD methods.)
How can we do calling JPA CRUD methods from my CRUD methods in
framework?
We will use this framework for desktop and web applications. Is
deployment a problem for us.
Do we have to use EJB?
Is there alternative to JPA which you suggest? (example: ADF,JDBC)
Thanks
It highly depends on your requirements and what you want to do with your "framework". I do not know enough of your project to give you a real advise, but here are some thoughts:
What do you mean with "framework"? Are you developing a library which other people should use? What should be the purpose of your framework? Is it a data access layer for some of your company data? If so: JPA is a kind of a standard and might be a good fit since it is widely used. If other people should use your "framework" it is good to use something which is standard and used in many other applications and tools.
Do you really need a data access layer on the desktop? Do you have a rich client? It is no problem to just "deploy" the application to the desktop, but a data access layer must always be configured and (maybe) updated. And that's where the pain begins when you use a rich client. Users must configure a database, the database must be installed or accessible remote and the version of the client must match the version of the database. Sooner or later this will hit you.
What else have you considered already? What about a ORM? Hibernate might by a good and popular fit. Also eBeans which is used in Play! is very cool. If you make a CRUD applications, frameworks like eBeans are doing most of the work out-of-the-box for you. You create a model (just POJOs + annotations) and the frameworks provides the complete data access layer (including the database setup).
Related
I have an application that uses SQL Server. I wanted to use a NOSQL store and I decided it to be graph since my data is highly connected. Neo4j is an option.
I want optimally to be able to switch the databases without touching the application layer, say, just modifying some xml configuration files.
I've taken a look at some examples public on the web, I've seen that ORM and OGM don't configure applications the same way, the config file of each has it's own name and more importantly its own structure. Looking at the code of each revealed that they also differ in the way they initialize the session, which doesn't sound good for what I'm thinking of.
My question is: "is it possible or feasible-without-great-overhead to switch between the two databases without touching the existing application code? I may add things but not touch what exists already". It would be a great idea to establish a pure polyglot persistence between SQL and NOSQL databases, for example, using Hibernate.
I want to hear from you guys before digging deeper. Do we have one of Hibernate men with us here in SO?
The goal of Hibernate OGM is to offer an unified abstraction for various NoSQL data stores. The project is still young, as we speak, so I am not sure if you can adopt it right out-of-the-box.
There is also the problem of transactions. If your application was designed to use SQL transactions, then things will radically change when you switch to a NOSQL solution.
Using an abstraction layer is good for portability but doesn't offer all the power of native querying. That's the same problem with JP-QL, which only covers SQL-92, lacking support for window functions or CTE.
Polyglot persistence is a great feature, but try using separate repositories, like Spring Data offers. I find that much more flexible from an architectural point of view.
I have created dao tier in my application. Now I want to generated web tier with basic crud operations in wicket. I read that apache ISIS can do this: http://isis.apache.org/. I successfully download and run their example and it look very good but I didnt find any tutorial how to replace their DAO tier with mine. So the question is how to replace it or is there better framework which can handle this task ?
Apache Isis is a full-stack framework, so you don't really need to write your own DAO layer. Instead, we leverage the JDO/DataNucleus ORM. Annotate your pojos and the ORM will do its thing.
The only persistence layer stuff you do need to write is specific implementations of your repositories, to use JDO queries. The example archetype that you have already tried out has an example of this.
If you have an existing database schema, you can adapt the JDO/DN ObjectStore to use it by using good old fashioned SQL views. For any non-updateable views, you can install "instead of" triggers. In fact, I'd argue this is good practice even for green-field projects.
I'm a .NET Developer trying my hand at Java. My current project has a UI layer, Business logic layer, and a Data Access layer. I'm currently working on the DAL.
I'm not connecting to an external database yet; I had hoped to have my DAL classes utilize in-memory dataTables until the DB is in place.
In .NET it's very easy to make in-memory dataTables, select from them, add to them, and remove from them. But, in Java, I've been unable to find something that does the same thing.
I was considering replacing the 'dataTables' with a collection of strongly typed objects; but that would require adding references to Business layer inside of the DAL (and I thought that was a no-no).
Can someone help a confused developer out? If this whole approach is flawed, what would you do? If I missed the equivalent of a dataTable in Java - what is it?
Here's an article on running an in-memory Derby database.
If I knew what database and what persistence library you're using, I might be able to give a more precise answer.
You could use a memory database like described in this answer.
A comparison of different memory databases is shown in this SO question.
I was considering replacing the
'dataTables' with a collection of
strongly typed objects; but that would
require adding references to Business
layer inside of the DAL (and I thought
that was a no-no).
Who makes up these rules?
If your data access layer is responsible for CRUD operations for model objects, it seems to me that it has to have references to them. There's no way around that.
The persistence tier need not know about the service or view layers.
The only completely uncoupled class is one that talks to no one and offers nothing. It's useless.
Don't be so hung up on "rules". You're trying to layer your application. You're putting all things about persistence into a layer of classes.
I don't think in-memory database has any effect on the way you design the persistence tier. You should be able to swap in a relational database or flat file or any other mechanism, but the interface shouldn't change. That's an implementation detail.
OR/Ms were available much earlier in Java than in .NET. DataSets are flawed in that they force you to program procedurally. Try to interact with objects and map those to the DB later.
I have a Java web application that has a 'disconnected' Java Swing desktop app. Using the desktop app users connect to the internet and download data they need from a server. They can disconnect and use the application offline. When they reconnect to the internet they can sync their data back to the server.
The server itself is a Java EE web application and the desktop app is a limited functionality version of the web app. Up until now all business logic and data access code was coded separately for each application. The data stores were different for each application (Web is SQL Server and Desktop is Serialized objects). Some new requirements involve a lot of development to both applications. Since the functionality is the same I want to layer the data access code and business logic so I can easily reuse it for both applications.
My plan is to do the following.
1) Create a DAO library (JPA)
Switch my DAOs (currently JDBC) to use Java Persistence API. This way I can start using a RDBMS on the desktop app like derby, sql express or something similar and reuse the entites and DAO code to do all of the db operations. I can bundle this into a class library and use the same library for the web and the desktop.
2) Create a library for business logic
The web app is written in struts 2. I will take all of the logic in my Action classes and but it in POJOs. Create a jar class library with the business logic. I can add the lib to my web and desktop project. Then I can call the POJOs from my struts actions and from my desktop application.
I assume that the JPA will take care of duplicating the data access code and putting the business logic (which for the most part are dao calls) in a separate library will take care of duplicating the business logic.
So my question is: What is a good strategy for separating layers for an application that can be used online and offline?
If you have any recommendations for achieving this differently, any warning for me as I begin this project or any frameworks that might help me please let me know.
What is a good strategy for separating layers for an application that can be used online and offline?
Well, your plan looks decent from a high-level point of view and will definitely simplify the maintenance of your applications. I don't have much to add: create JPA entities, a service layer, and if you feel the need, a DAO layer1. Then use these parts in both of your applications, with different JPA settings.
Here are a few additional notes:
I would go for a full Java database on the desktop (derby), it will be easier to manage its lifecycle.
Spring would provide good overall support (for layering, for declarative transaction management).
JPA doesn't provide any facility for the merge or databases, you'll have to implement that yourself and handle painful things like conflicting changes, etc.
1 I would actually even consider skipping the DAOs and accessing JPA's EntityManager directly from the service layer. Some people might not agree with this but the fact is that the EntityManager already implements the Domain Store pattern which does pretty much what the DAO pattern does and and there is not much value at shielding it behind a DAO.
I have a java web application built on Stuts2/Google Guice/JPA. It uses hibernate as the JPA vendor. I would like to add support so it can be used on Google's App Engine. Of course I'm running into issues with the queries and mappings. Such as Many-to-Many and joins not being supported.
I'm trying to come up with the best solution for keeping my app able to be standalone. For example sin a tomcat/jetty on any database the JPA vendor supports or Google App Engine with datanucleus as the vendor.
One solution I thought of would be to use JPA for my standalone implementations and JDO for Google's App Engine. Obviously this would require me to annotate my model objects with both JPA and JDO annotations and to write another implementation for the DAO layer.
Are there any other good solutions that others have tried?
I think your approach is a good one. I think a well design architecture is the best approach. You will most likely see a lot of variance in the DAO layer. A good design would see a DAO interface, then each specific model access would have its own implementation of that interface e.g. JpaMyObjectDAO, JpaGAEObjectDAO etc. Also like you siad, App Engine has some special requirements when it comes to declaring your entity classes. Perhaps you could have different versions of the entity classes (each that conforms to its storage scheme like App Engine or Hibernate), then have a common DTO representation for your higher layers to use.
You could relocate your queries to an XML configuration. This way you can have queries for a RDBMS in one configuration and your queries for BigTable in another configuration.
Another idea is that DataNucleus is a JPA vendor as well. You could probably ease your development by making it your primary JPA vendor on both GAE and your Servlet Container. JPA vendors often times have very slight differences between what they do with their metadata and this may save you some headaches.