This is a very simple sub-generator, compared to the "entity" sub-generator.
Its goal is to generate a Spring Service bean, which is where your application's business logic is supposed to be coded.
In order to generate a "bar" Service bean, just type:
yo jhipster:service bar
This will generate a simple "BarService": very few lines of codes, but they usually come with a lot of questions. We are trying to answer the most common ones below.
We have two main architecture principles here:
Short answer: No.
If you want the long answer, here it is:
One of the main interests of using Spring is AOP. This is the technology that allows Spring to add new behaviors on top of your Beans: for instance, this is how transactions or security work.
In order to add those behaviors, Spring needs to create a proxy on your class, and there are two ways of creating a proxy:
Some people will also argue that interfaces are better for writing tests, but we believe we shouldn't modify our production code for tests, and that all the new mocking frameworks (like EasyMock) allow you to create very good unit tests without any interfaces.
So, in the end, we find that interfaces for your Service beans are mostly useless, and that's why we don't recommend them (but we leave you with the option to generate them!).
By default JPA uses lazy initialization of one-to-many and many-to-many entity relationships. If you use this default configuration, you will probably see the dreaded
LazyInitializationException: it means you have tried to use an un-initialized relationship outside of a transaction.
As the generated Service class has by default the
@Transactional annotation, all of its methods are transactional. This means that you can fetch all the required lazy relationship inside those business methods, whitout any
@Transactional(readOnly = true) on a method if you are not modifying any data. This is a nice performance optimization (Hibernate won't need to flush its 1st level cache, as we are not modifying anything), as well as a quality enhancement with some JDBC drivers (Oracle won't allow you to send INSERT/UPDATE/DELETE statements)
Yes! Just add the standard Java
@RolesAllowed annotation on your class or on your methods, and use the provided AuthoritiesConstants class to restrict access to specific user roles.
Yes! Just add Metrics'
@Timed annotations on the methods you want to monitor.