I have a small Java web application built and I'd like to convert this to a Grails web application. My Java web application consists of Servlets, entity and hibernate for the database, and plain old java objects classes. So What's the best way of going about doing this?
I agree with Joshua for the most part. I have helped prototyped moving a java web service to Grails. I would first start with understanding the roles of the classes inside Grails (Domain classes, Controllers, Services, Filters, and CommandObject) and mapping on a whiteboard what does those roles in your current application. With hibernate as the database layer, that should be easy to port, and many service like classes can be moved over as-is. The tear up is going to come at the controller level, so make sure you think that through carefully.
You might think about refactoring your code in the Java space first if your current application does not separate responsibilities well. The cleaner your code, the more you can re-use as Grails services.
Starting with an empty Grails project I would begin by using your existing POJOs and creating Domain classes in the Grails project. From there I would then begin to model the behavior of the Servlets into Grails controllers, services, and filters. Finally I would finish with cleaning up the views and applying the styles.
That's how I would approach converting it.
Related
I have developed some MVC applications by using Entity Framework code first approach and now I am developing a new application that will also use web services for mobile applications that we will create. So, I have trouble about the issues below. Could you clarify me please one by one regarding to the issues?
Which web service technology should I use i.e. Web API, WCF, etc? (I am using MVC5 and EF version 6 in my project)
Can I use the same CRUD methods for my web application and for web services? If so, which modifications should be made on the methods and on the other fields i.e. models, etc?
For a current MVC application where EF code first approach was used, is it better to create a new methods for web services or should the current methods be updated by adding ability to support also web services?
Thanks in advance...
I highly recommend to use Commands and Queries. It's covered in this and this articles.
The Command is simple DTO object, and it could be easily sent over the network. In this case you have control over the fields and behaviour you want to make public.
Because commands are simple data containers without behavior, it is
very easy to serialize them (using the XmlSerializer for instance) or
send them over the wire (using WCF for instance), which makes it not
only easy to queue them for later processing, but ot also makes it
very easy to log them in an audit trail- yet another reason to
separate data and behavior. All these features can be added, without
changing a single line of code in the application (except perhaps a
line at the start-up of the application).
I'd like to make my usage of open-dolphin in grails sever as easy as possible. So, I'm looking for way to handle CRUD actions on domain classes(on the server side) automaticaly. In demos from open-dolphin project I havent found any idea how to achieve this(if I missed something, please point me where I should study). Instances are pulled from server on request and until it would be pulled/updated again there is no way to recognize changes that happen on server(I've been investigating mainly crudDemo in open-dolphin project).
Since CRUD actions can come not only from user via web or remote client, but also as consequence of other actions, cascade deletes, from services etc.(changes made to the database via sql, are probably untreatable), I thing that handle actions in classes controllers is not enough.
I came up with idea of handling CRUD actions using GORM events, with those I can keep dolphin models persistent with database, check PMs before update or delete, and probably handle all changes on domain classes instances that grails is doing. But, I have to write very similar logic to each class, be sure I havent missed any event on any class(scaffolding may help) and there are probably other consequences that I do not realize now..
So my question is: Is there any documentation, pattern, plugin, open-source code, etc., where open-dolphin is implemented into grails that way, that it autamaticaly propagates CRUD actions on domain classes instances to its presentation models? Or anything that aims to achieve this, using scaffolding, observing instances lists and properties, or something else?
Maybe, I misunderstood concept of using open-dolphin with grails, if so, I appreciate any good advice.
Thanks a lot!
for some reason I haven't seen your question before.
You can happily use Grails domain classes and GORM with OpenDolphin on the server side. The "CrudDemo" in OpenDolphin does exactly that.
Here are the domain classes: https://github.com/canoo/open-dolphin/tree/master/dolphin-grails/grails-app/domain/dolphin/grails
Here are the actions: https://github.com/canoo/open-dolphin/tree/master/subprojects/demo-javafx/server/src/main/groovy/org/opendolphin/demo/crud
Note that when we do testing and client and server-side actions run in-memory, there is no grails support available. Therefore, the server-side actions use service interfaces with DTOs instead of Grails domain classes. The implementation as a Grails service then uses Grails domain classes and GORM.
enjoy
Dierk
I'm building a new SAAS application and was looking for some advice on the most appropriate framework to use. I realize that no single framework will likely be able to do all this, but I thought I'd ask the community and try to find one that solves the hardest problems.
Requirements
Single code source. (each customer will have either a subdomain, or a distinct domain, but everyone should be running off the same code base and same servers)
Should be able to update the programming source once and have all the tenants pick it up
Session information should either be kept in a cached store, or just in cookies (no shared state)
Multi-tenant database functionality built in. (Based on the domain used to reach the application, the framework should automatically use the database connection information assigned to that domain)
Each customer/domain may have their own template for the web pages. Templates need to be assignable on a per-customer basis and kept outside the application code
Security and rapid prototyping is more important than speed
There will be a lot of CRUD type screens, so simple built in functionality for this is desired
I have pretty lengthy Java and PHP experience, but would only consider PHP as a last resort for this. My Scala, Python and Ruby experience is a bit rustier, but I would not mind coming up to speed if they offer a significant advantage. I've looked at the Play! Framework and like it (fulfills #1, #2,#6 very well), but the multi-tenant aspects are not very strong. I've done several projects using Grails and it handles everything except #3 and #5, and can be hacked to do the rest.
I would say that the third point is rather independent of grails/play/whatever in general. If you need a shared cache there is a multitude of providers for this and there are plugins for most of them in Grails.
The multi-tenancy in grails is pretty mature and much less intrusive than the solution from the blogpost in Sebastiens answer. Whether or not you use single tenancy (multiple databases) or multi tenancy is more or less transparent to your code and most of the headaches are abstracted away. Do be aware that you need to do some smart indexing (like including the tenant id in a multi column index etc) to not get very sad speeds when your data starts to grow.
As for externalized views, you can either slap them in the database or symlink them into your webapp and just keep them in separate numbered folders. Then from the tenant plugin, you can use TenantUtils.getCurrentTenant() and simply render from the appropiate folder "/" + (tenantID ?: "default") + "/whatever/view/path". This way, layouts etc can be shared across tenants if you so please and you simply put tenant specific stuff in the tenant specific folders.
You can probably do this in play too, or , but I don't see anything hindering you from doing this just fine in Grails.
My $0.02 on this question.
Actually Play! fits well to what you'r looking for.
Read this post:
http://www.lunatech-research.com/archives/2011/03/04/play-framework-writing-multitenancy-application-hibernate-filters
It works great. You can even make this filter work so that you can expose the crud module to customers and they'll only get their own data...
For very large applications, sharding seems not supported yet (no hibernate shards handled yet i think).
There's a multidb plugin to work with multiple db, but it seems not working very well yet...
I've heard that Grails' Multi-Tenant plugin offers some good tooling for several different methods of multi-tenancy.
"Each customer/domain may have their own template for the web pages.
Templates need to be assignable on a per-customer basis and kept
outside the application code"
I assume you mean they each have their own layout/skin. There are several techniques to execute this:
You could manually assign layouts based on tenant. <meta name="layout" content="${tenantName}/main" />
Write your own tenancy aware LayoutDecoratorMapper and override the default GrailsLayoutDecoratorMapper in sitemesh.xml
Figure out how to override and enhance Some internal tools dynamically resolve views(per tenant) or resources (GrailsViewResolver, GrailsConventionGroovyPageLocator, GrailsResourceLoader, etc.)
In PHP you can use Innomatic Platform for building multi-tenant (isolated databases) applications:
http://www.innomatic.org
If I know Rails, what new ideas/patterns would I learn if I looked at Grails?
I have no intention to move to Grails and no need for a Java stack, but if there are neat ideas I could learn from Grails I'd like to learn them.
Grails has taken totally different direction. It is very hard to compare Grails and Rails.
Grails is not framework. It is stack of frameworks. You can find all the features you find in plain Spring, Hibernate, Quartz, Compass, Sitemesh frameworks. So at the end you get all the best from all these frameworks with convention-over-configuration.
However, I really want to mention about very interesting idea introduced in Grails about modulizing the application into plugins. Plugin in Grails is minimized independent project. Separating application logics into plugins allows to share your code to community and keep application in separate modules which results in easier testing and easier development.
Grails has at least two patterns I'm aware of that I believe do not exist in Rails:
Command objects (and auto binding request params to them)
Conversation based request handling using web flows
I'm new to grails. I'd like to give it a whirl by implementing a new feature or two into an existing Java EE application. The current Java EE app is a fairly standard Spring MVC/Hibernate app running on Tomcat. Looking through the documentation, it looks like I should be able to leverage all of the current business logic that's written in Java.
I've only been able to find tutorials on creating new grails applications. Does anyone know of a tutorial for integrating with an existing Java EE app? If not a tutorial, any recommendations or suggestions on where to start?
Whether or not those features go live would depend on my experience with Grails and if I think it's worthwhile using it going forward. The goal would to either:
Decide Grails isn't for me (and not deploy grails).
Decide it is for me, and all future development on this app would be in Grails with a full eventual port over.
I'm afraid I don't know of any such tutorials, but my immediate thought would be that porting an application while also combined with learning Grails could be a big uphill.
I haven't done this sort of thing before, so these are just musings on how I might approach doing this..
Since GSPs are not analogous to JSPs and since Controllers in Java are statically typed, whereas Grails controllers have magic methods wired onto them, I would probably want to re-write those again in Grails from scratch since their transferability isn't obvious - the logic should transfer but the boilerplate of the old code isn't altogether necessary for the most part.
Maybe take a simple story/feature, keep the existing Services it uses and get them wired in via Spring in Grails. Then try making one for one copies of what you have in Java with corresponding Controller/GSP and Domains. That should give you some feel of what stuff you need to get off the ground for the port.
Your biggest struggle, from people who I have heard of doing this, might well be trying to re-use your existing hibernate stuff in Grails.
Just my tuppence, not so much a whole answer...
Insert Grails into an Spring app is not easily achievable, you can try to insert the old Spring app into a Grails app, and continue from that point.
Here you've some info 'bout using the hibernate mappings and java classes.
You also have to have to add the beans of the Sprint app to the Grails app. You can insert them into the ApplicationContext directly or use the resources.xml or resources.groovy.
It depends on how you've written the Java EE app. You cannot drop it into the Grails runtime and expect it to work with no tweaking, especially the 'controller' part of your app (since grails uses its own conventions for that). The UI, if its jsp, may be a bit better, since you can probably rename them to gsp, and have it work. tag libs works straight away, and normal java classes work straight away obviously. Hibernate objects may need tweaking - though i suppose it may just be easier to redo those using grails.
-my 2cents