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.
Related
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.
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
I'm designing a shopping cart web application in Java.
Many Java applications seem to adopt the same naming conventions which I would like to use.
For instance:
_ - entity which is persisted to database
___DAO - DAO which provides CRUD methods for persisting Item to database
___BO - I've only seen these used as a thin wrapper around DAOs. Is there any other point to these?
___Service - Used to expose API?
How do most designers split code between BO and Service?
If you are not using EJBs I think there is a little confusion. Your objects you are naming "entity" objects are the Business Objects. In a POJO based application BOs represent the domain. Take a look at this sample project: Spring's Pet Store.
The "domain" directory contains the BOs.
Note that there is a "service" and a "dao" directory, which obviously contain the respective services and DAOs.
I would use DAOs in service directly (no BOs) and point of service layer is to add caching, transactional stuff like thing also you could easily expose them as webservice if required
I am trying to use the DAO pattern in my multiple web app projects. I have three different web applications and they share two different databases. Each databases have number of tables.
Now I am wondering how I can make my program modular by using best practice. I am thinking of making:
DAO project which have two factory class for each database, DAO interfaces for each tables and DTO for each tables.
Then in each web app project I am planning to write implementation code for DAO interface and necessary utility class for getting and closing the connections.
Is this approach good? The doubt/problem i am having is with this design if I am going to ship any one of the project I have to ship DAO project also but that will contain unnecessary info about other databases.
Or will it be good to attach all necessary DAO in web app itself? If so then I have to write same DAO ode for each web app.
Hope anyone can provide me the clear path for this DB connection using DAO pattern.
In general, you're headed in the right direction by separating your concerns.
You mention the multiple web apps rely on the two databases. Does each web app rely on both databases? If so, I'd consider creating a single DAO project to encapsulate all the data access logic.
If it's more a mix and match (web app a uses db a, web app b uses db b, web app c uses a and b), I'd consider having two DAO projects, one per database, unless there's a lot of combined logic - that is, when an app uses both databases, it's doing joins between them [yes, I have had projects that do this].
I'd also recommend looking at an Object/Relational Mapping (ORM) framework such as Hibernate and/or a Dependency Injection framework such as Spring, which can help simplify the process of separating the various projects and then using them together.
You're clearly planning a pretty ambitious project, so taking advantage of existing frameworks to minimize recreating the wheel will let you focus on your specific problem domain.
Use JPA to access DB. If not possible then use JdbcTemplate (Spring)
EntityManager (JPA) is a kind of a DAO
DAO only where it makes sense (e.g. complex, reusable logic using an EntityManager)
Use pooled connections/ DataSources
DTO are usually only needed if your objects need to leave the JVM (e.g. remote EJB services, web services,...)
use EJBs for container-managed transactions
consider the Gateway pattern (a stateful session bean and an extended persistence context, see "Real World Java EE Patterns – Rethinking Best Practices" by Adam Bien) and just return the attached entity.
I started experimenting with Spring Roo just recently. It does a very nice job helping one build a domain model with integrated persistence rather quickly. As it adds persistence functionality in aspects, I started think about the following question:
Roo adds finders (load an instance of a class from the database which meets variable criteria) in an aspect to the actual class/entity. In DDD this is IMHO the responsibility of repositories. Repositories are explicit classes which show up in the design. Of course as an aspect the repository functionality is hidden in an entity and is pretty much invisible.
So here is the question: Is an aspect a real substitute for a explicit repository class? Are there any downsides to the Roo AOP approach?
Adding finders to your domain classes feels more natural from a user's point of view but it mingles your layers. Grails uses the same approach by adding static finder*() save(), ... methods.
Apart from the aestetics it might have practical drawbacks when not used in web application setting:
Your domain classes are now tied to your database. If you transfer these objects to rich clients via RMI or HttpInvoker the client cannot and often may not use the find* methods because there is no session / database connection available on the client.
I generally prefer allowing domain classes to reference service layer interfaces to prevent an anemic domain model (http://martinfowler.com/bliki/AnemicDomainModel.html). This has its own set of drawbacks but at least provides a clear boundary. On the client the concrete implementation behind a service interface can then just proxy all method calls to the server (or just use a synamic proxy with spring remoting or sth similar).
So to answer your question: It might be a substitute but you should be aware of the possible negative consequences which make your domain classes (i.e. your core business logic) less portable between systems.
This depends on how complicated your applications persistence layer is and how much control you have over it. If your application is simple enough to be implemented via JPA, then it all could be handled via Roo aspects. However if you are mapping legacy tables or need advanced DB stuff, then you may find yourself in a situation where Spring-JDBC is the only way out and in these cases a repository/dao model may still be useful.
I consider it logical inconsistent (and a break of layer responsibility) to be mixing two persistence models and so as most of my applications requires such advanced DB constructs I stick strictly with a repository model.
I think adding repository methods to domain objects is bad design. The right place would be static methods in the domain class. But domain objects and their management are two different things that should be separated. I would prefer domain objects and repositories.
I guess the motivation was to achieve something Rails/Grails like with Java.