I have implemented a Data Access Layer by mean of Spring-Data's facilities. At the moment I use the Hibernate Tools (in Eclipse) to generate the annotated EJB3 Entities of the tables of my DB.
Clearly the fetched data should flow through my application layers so I need to implement the Domain (as Spring calls it) part of the application. Theoretically the Domain should be a agnostic-to-the-implementation POJO, meaning it should not contain Entity's annotations.
Keeping in mind that the Entity is unavoidable to make things work, what is the usual behaviour? Should I create a Domain class library which simply mirrors the Entity data and is only a POJO (with the help of Dozer to make the copy part) or should I use the Entity even outside the DAL (thus losing the Domain's agnostic-to-the-implementation attitude)?
Thank you in advance
Giulio
Related
I am working on a multi module java project and I ended up creating a module for the shared model and services.
I have a problem because one module (using Spring Data REST) uses JPA entities and they need to be shared with other modules in the form of simple POJO (without database sync). At the moment I have duplicated code without any JPA/Hibernate annotations but this is surely not the way to go. Any clue how I can proceed please ?
JPA allows to define the mapping in XML using orm.xml. A real life exmaple can be found at here and here.
For me , though the POJO become more clean when the mapping is defined in orm.xml , it seems to require more effort when compared to annotation and also make the codes look like less readable and maintainable . I would be more pragmatic to just let them annotated with JPA annotations. If a module only need to use them as the plain POJO but not JPA entity , just not include the JPA implementation and the JPA annotation will simply be ignored.
I have worked with Spring MVC for a while and think about to create an application with plain Spring (Spring Boot may be). I will have few domain data objects like:
- Person
- Address
But first application version will be built without Address class. I do not know what fields will be stored in Address class. Also I want to make app with Hibernate (so Hibernate will create DB tables for instances classes). So I have options:
-Create Person class at first, without address field, but it will be incomplete, and will need tests update when Address will be in system.
-Create Address interface and make some implementation like MockAddress or StubAddress and create a data field in Person Class with Address interface type.
-Create Address class without any interface and fields/methods and wire it with person.
I not find good explanation for this topic, so how to use DI there or is it worth not to use it? Most articles I find about service layer wire, but not about data model objects.
The power of dependency injection (DI) is not in the domain model; e.g., you likely won't benefit from DI in the person-to-address domain model relationship. Your persistence data model, i.e., your database + Hibernate, should maintain the domain model relationships.
Managing your application configuration, however, is a perfect place to use DI to assemble a production ready application. Configuring service layers is another great spot to use DI. Using dependency injection is well-worth your time and effort to learn, even for the most basic Spring applications like what you have described.
To get you started, here's a simple example using Spring Data JPA with Hibernate. To upgrade your database as your domain model changes, use Flyway.
As far as I know, there are two ways to configure JPA / Hibernate:
XML based configuration through something like hibernate.cfg.xml. I don't like his approach because, well, XML ...
Through annotations in the entity object. Much better than the XML config, but it couples my entities to JPA.
As I am currently investigating an architecture where the domain model does not know anything about the database (The 'Onion' architecture), I am looking for is a way to specify the mappings without changing my entities.
Of course I could create separate mapping classes, e.g. if I have a Customer domain object, create a JPA-annotated CustomerEntity and let the repository translate from one to another. But this approach doesn't feel quite right because the Customer and CustomerEntity will essentially be the same.
So it seems like I have to resort to Hibernate XML configuration, but as mentioned before, I don't like that approach.
Spring has a nice way of configuration: Java-based configuration. I was wondering if there is something similar for Hibernate/JPA configuration, and if not, why not?
My apologies if none of the above makes sense, but any help is welcome, even if it doesn't answer my question :-)
I've never heard of an Onion Theory of Java EE design. I did hear of The Onion, but that's a satirical newsletter (if that :-). Separation of concerns in Java EE I typically expressed as a MVC, or Model View Controller architecture. Your JSP or JSF pages will be your view, your #ManagedBean controllers will be your controllers, and your model will hold your Entities.
The model, which is where the JPA will be, can usually be further separated into a Service Layer, a Persistence Layer and EIS (Enterprise Information System) or Database tier. The Service tier will hold your EJBs, annotated with Stateless, Statefull or Singleton, and will encapsulate the business logic for the application. The Persistence Layer will have #Entity annotated objects that are stored by the Database.
Java EE defines these layers with JSR's, with numbers of some sort. For example, the Java Persistence API (JPA) is JSR-220. Tests are developed against these JSR's and if a vendor meets these tests then their product can be (More or less) swapped out for another vender's version.
Apparantly there is somethinig called Fluent NHibernate for C#, which does exactly what I was looking for.
Unfortunately, there seems to be no "Fluent Hibernate" for Java.
There is a fluent-hibernate project on GitHub, but that one seems to be about fluently writing HQL-queries, not about mapping configurations.
Currently I am working on a project with Spring web-service, hibernate and JAXb.
1) I have generated hibernate beans using IDE 'hibernate code generation,
2) also, I have generated the jaxb beans using maven compiler.
..
Now, my question is,
1) Is this the right approach? (to have so many beans).
2) Shall I use JAXb beans for processing into the service layer? How can I keep layers decoupled?
3) Or, do I need to create another set of beans ie. map (JAXb beans) to (new beans) to (hibernate beans)?
.
Please tell your views?
Thanks,
adi
You know, you cannot have everything fully decoupled. There will be always a layer that will know the other two layers.
Usually when I design 3 layers architecture, like:
Service Layer - the one that probably uses JAXB, exposes web services or other APIs
Business Layer - any real logic
Persistence Layer - hibernate
I allow the Business layer to know about the Service Layer (JAXB) and about the Persistence Layer (hibernate beans). But I don't allow the Service Layer and the Persistence Layer to know about each other.
Note: I'm the EclipseLink JAXB (MOXy) lead and a member of the JAXB 2 (JSR-222) expert group. EclipseLink also provides an excellent JPA implementation (open sourced from TopLink).
There are costs to maintaining multiple models. Each model you add introduces a bean-to-bean conversion that must be written, tested, and maintained.
Another approach is to use the same beans for both the JPA and JAXB bindings. For this use case it will be easier to start with domain model and add JAXB & JPA metadata to apply mappings to XML and the database. Below is example of where a single model is leveraged to create a RESTful web service:
http://blog.bdoughan.com/2010/08/creating-restful-web-service-part-35.html
Since EclipseLink provides both JAXB and JPA implementations we provide a number of extensions to make this easier:
http://wiki.eclipse.org/EclipseLink/Examples/MOXy/JPA
http://blog.bdoughan.com/2010/07/jpa-entities-to-xml-bidirectional.html
UPDATE
In response to:
Agree to what you are saying. However, using same beans will couple
the code very tightly and will be highly dependent. Change in one
layer will need changes elsewhere as well. What you say?
It all depends how you look at things. My preference for building data access services is to design and build a solid domain model. Then use JPA and JAXB to solve the impedance mismatches between object-relational and object-XML.
One Model Approach
Using one model for both JPA and JAXB means that when you make a change to the model you need to decide at that time how it will be handled for both JPA and JAXB (this can be good or bad). If you don't want every new addition to the model to affect the JAXB mapping you can leverage JAXB concepts like #XmlAccessorType(XmlAccessType.NONE).
http://blog.bdoughan.com/2011/06/using-jaxbs-xmlaccessortype-to.html
Two (or More) Models Approach
When you want to add a field that is mapped to both relational and XML you need to add it to two models and add the necessary conversion logic. In this case there is a cost to keeping the models de-coupled.
I've noticed where I work, that we have a tendency to put our Service level objects into our entity package. This made me wonder if my concept of an entity class was wrong. I though entity classes represented a table in a relational database, am I correct? If so, where would you recomend putting these objects, perhaps in a Service objects package?
I logically separate them based on their concern. The point of even having a Data Access layer, Service layer, etc. is separation of concerns. I tend to go a little over board, but I do something similar to:
app
--model
----PersonEntity.java (JPA annotated entity)
--service
----PersonService.java (interface)
--web
----PersonController.java (SpringMVC Controller, Struts action, etc.)
--internal
----PersonServiceImpl.java (Contains JPA EntityManager, e.g.)
That is, if you intend to keep everything in the same project. I would probably separate the service and model code into it's own project, in case (for example), you might write a separate web service and reuse the same domain model.
FYI, I'm not a fan of DAOs, but they're pretty prevalent. I'm not sure where I would put a dao, but I'd probably follow the same convention. An extra package is just another folder, it's no biggie, and makes sense to organize your code as much as possible.
Where I'm at, we define the entity object in a package within a module. Then, the service interface will be in the same package, in the same module, but the implementation will be in the same package in a different module. It can be nice to keep all the code related to EntityX within the same package; that includes the Entity, Dao, and Service definitions and implementations.