In my project i have multiple liferay plugin portlets. I have used single plugin in portlet having service builder. All other plugin portlets are using same service builder portlet.
Ex:
Portlet1, Poertlet2, Portlet3 and ServiceBuilder portlet. Portlet1, Poertlet2, Portlet3 are using same ServiceBuilder portlet.
This service builder is connected to external database. And i am inserting/fetching data from this external database. There are one to many and many to one relationship structure in database. I want to use hibernate relationship model for these relationship and run complex queries to fetch data. So i want to use hibernate session factory in my service builder.
Please give your valuable advice or code so that i can do this as per the requirement.
Please note:
1. I have read about liferay relationship in tables. But this has not work as per my requirement.
2. Most of tables are managed by other application. I am using their data only.
Service builder does not work this way and if you want the relation you should not use it.
The idea behind service builder is to have an easy DB access layer - entity at a time and the relations are resolved in the business logic.
If you want that the relations are handled by the persistence layer you need to use plain hibernate.
Related
I am not sure whether my approach with the MVC environment in JSF is the best way to go. Since I am trying to get the most out of JSF I would like to know how my Service Layer (or Model, speaking in MVC terms) should be 'designed'.
I know the View-Controller ratio should be 1 to 1 (exceptions ruled out).
Now in what way should I design my Service Layer? Should I use one big service (don't think so)? If not, based on what should I split my services?
Note, my Service will be called from the Beans (Controllers in MVC terms) and the Service itself will call DAO's using JPA when necessary.
Thanks in advance
The service layer (the business model) should be designed around the main entity (the data model). E.g. UserService for User, ProductService for Product, OrderService for Order, etc. You should absolutely not have one huge service class or so. That's extreme tight coupling.
As to the service layer API itself, Java EE 6 offers EJB 3.1 as service layer API. In the dark J2EE ages, long time ago when EJB 2.0 was terrible to develop with, Spring was more often been used as service layer API. Some still use it nowadays, but since Java EE 6 has incorporated all the nice lessons learnt from Spring, it has become superfluous. Note that EJB (and JPA) is not available in barebones servletcontainers such as Tomcat. You'd need to install for example OpenEJB on top of it (or just upgrade to TomEE).
Regardless of the service layer API choice, best would be to keep your JSF backing bean (action)listener methods as slick as possible by performing the business job entirely in the service layer. Note that the service layer should by itself not have any JSF dependencies. So any (in)direct imports of javax.faces.* in the service layer code indicates bad design. You should keep the particular code lines in the backing bean (it's usually code which adds a faces message depending on the service call result). This way the service layer is reuseable for other front ends, such as JAX-RS or even plain servlets.
You should understand that the main advantage of the service layer in a Java EE application is the availability of container managed transactions. One service method call on a #Stateless EJB counts effectively as a single DB transaction. So if an exception occurs during one of any DAO operations using #PersistenceContext EntityManager which is invoked by the service method call, then a complete rollback will be triggered. This way you end up with a clean DB state instead of a dirty DB state because for example the first DB manipulation query succeeded, but the second not.
See also:
Creating master-detail pages for entities, how to link them and which bean scope to choose
When is it necessary or convenient to use Spring or EJB3 or all of them together?
JSF Controller, Service and DAO
The 1:1 ratio between services and model entities maybe not bad if you have few entities in your app. But if it is a big app, there would be too much services.
The number of services depends upon the use cases of the app you are designing. Once you have identified them in the analysis phase, you must group them in several groups according to their functionality. Each group of use cases will be a Service, and each use case will be a method in that service. Each Service can manage several model entities (and you have to inject in it the DAOs it needs to perform its functionality). Usually the uses cases of a Service manage model entities inter-realationated in the class diagram of the model. The Services might follow the good practice of "max cohesion / min coupling".
The ratio between DAOs and model entities is 1:1. Each DAO perform CRUD operations and queries of its entity. If a method needs to query 2 relationated entities, put it in the more suitable DAO depending on the business concepts.
In the JSF presentation layer I neither have a 1:1 ratio between pages and controllers, that would be too much controllers. I group into one contrller all the pages needed to perform the use cases of each service. So the ratio 1:1 is between controllers and services, injecting each service in the controller whose pages perform its use cases.
Of course, these are general principles. You may have some particular cases in the app that broke them, but they are few.
You might not have too much services and controllers, but not too few neither because then they would have too much logic and fields. You must acchieve a compromise.
I am trying to design a application using domain driven design, i have a doubt regarding storage of an entity data. First i am creating an entity and applying business rules on the entity. Finally i want to store this data. I am using repository pattern to abstract the database operations. Now where i need to place code related to saving the entity data to database. Is it goes in the entity? or a domain service?
Persistence related code would go in the infrastructure layer. I usually put this in it's own assembly and inject the specific implementation of my repositories into my application layer.
You definitely do not want any database code in your entities or domain services.
We have a SQL Server with multiple database (different schema) and i need to develop an application in ASP.NET MVC & Entity Framework to connect to any of these database in runtime and perform DML operations. If a new database is added to the SQL Server then the application should able to connect to this new database without any configuration/code change. I am exactly looking for DML operation handled by myLittleAdmin
Can anyone advice me on this please
Unfortunately you won't be able to do this with Entity Framework. Entity Framework operates in two different instances, Code-first & Database-first.
The former being writing your relevant model classes for your data first and then Entity Framework will work out a database schema based upon those classes handling foreign key references etc automatically based on the references between models.
The latter is effectively the opposite, you define the database schema and Entity Framework produces the model classes from this. I have always found this method to be cleaner as you have more control over the database structure and I find it more difficult to make mistakes.
In your situation Entity Framework needs to know before hand the structure of the database to enable it to read from it so it cannot "connect to this new database without any configuration/code change". If you can provide more information about what you are wanting then I may be able to help.
I recently created an asset management system which could store generic assets which would traditionally be stored in separate tables, this solution was developed using Entity Framework but the database was designed in such a way that it could handle generic asset objects and store them i.e. if we created a new asset type then no database change was required hence there was no code change for Entity Framework either.
I am new to liferay, Can anyone please suggest some way to generate the service.xml for existing database Discussion on Liferay Website . I hope people might have developed some way or liferay have developed some plugin for this.
I see no particular use in introducing servicebuilder to large existing databases: You can connect servicebuilder entities to "legacy datasources" or "legacy tables" (those make good search terms) but service.xml generation has not been done AFAIK.
Some problem with this approach are:
servicebuilder has certain assumptions about operations in a database. It's done to encapsulate all different databases that Liferay runs on, thus might not use every database to its fullest extent possible
If you have a large existing database, you probably have a lot of existing business logic to make sure correct data goes in and out of the database. You might even work with stored procedures etc.
While you can make servicebuilder work with stored procedures, you'd have to introduce custom sql to work around servicebuilder's assumptions. Same goes for explicit foreign key relationships etc.
My recommendation is to rather have a proper interface on the existing business logic, e.g. Webservice, JSON, Rest, whatever is popular. Then use this interface in Liferay's portlets.
Another option might be to bring the existing persistence code into Liferay and just expose services without making use of the persistence features of Servicebuilder. For this you'd just define empty <entity> blocks (with names etc). This will generate the appropriate DoSomethingLocalService, but omit the persistence implementation - and you can wire your existing code in these services.
You can go through below link to understand Service Builder in liferay
https://www.liferay.com/documentation/liferay-portal/6.0/development/-/ai/service-build-2
Also below link have sample service builder portlet
https://www.liferay.com/community/forums/-/message_boards/message/17609606
Hope it Helps !
Not done yet AFAIK. Since Liferay directly doesnot support all data properties of DB like foreign key, one to n mapping etc, it is a challenge to create the reverese engineering. But you can give a try.
Service Builder is generally a nice feature to create relatively small databases, and simple business Logic, while giving you the advantage that your tables will be auto-generated when you deploy your portlet, and having finders (search by X attribute) with no effort. If this is the case with your database, it will be much easier to create a new service.xml from scratch.
Other that that, I think that having an extended database in Liferay's Service Builder will introduce more problems and slow development while you're implementing a complex business Logic, create custom Finders whenever you need to query on a join of tables and so on. So it seems quite normal to me that a conversion of a database to Service Builder is not available.
In other words, if your database is too large to write it in service.xml, you shouldn't use Service Builder in the first place
I am researching to start a new project based on Liferay.
It relies on a system that will require its own data model and a certain agility and flexibility in data management as well as its visualization.
These are my options:
Using Liferay Expando fields and define their own data models. I must do all the view layer.
Using Liferay ECMS adding patches creating structures and hooks that allow me to define data models Master - Detail. It makes much easier viewing issue (velocity templates), but perhaps is the most "dirty" way.
Generating data layer and access to services with Hibernate and Spring. (using Service Factory, for example).
Liferay Service Builder would be similar to the option of creating the platform with Hibernate and Spring.
CRUD generation systems as OpenXava or your XMLPortletFactory
And now my question, what is your advice? What advantages or disadvantages do you think would provide one or another option?
Thanks in advance.
I can't speak for the other CRUD generation systems but I can tell you about the Liferay approaches.
I would take a hybrid approach.
First, I would create the required data models as best as I can with the current requirements in Liferay Service Builder and maintain them there as much as possible. This would require that you rebuild and redeploy your plugin every time you changed the data model but would greatly enhance performance compared to all the other Liferay approaches you've mentioned. Service Builder in that regard is much more rigid and cannot be changed via GUI.
However, in the event for some reason you cannot use Service Builder to redefine your data models and you need certain aspects of it the be changed via GUI, you can also use Expandos to extend the models you've created with Service Builder. So, it is the best of both worlds.
On the other option, using the ECMS would be a specialized case and I would only take this approach if there is a particular requirement it satisfies (like integration with the ECMS).
With that said, Liferay provides you many different ways to create your application. It ultimately depends on how you're going to use your application.