I'm new to Flex development, and RIAs in general. I've got a CRUD-style Java + Spring + Hibernate service on top of which I'm writing a Flex UI. Currently I'm using BlazeDS. This is an internal application running on a local network.
It's become apparent to me that the way RIAs work is more similar to a desktop application than a web application in that we load up the entire model and work with it directly on the client (or at least the portion that we're interested in). This doesn't really jive well with BlazeDS because really it only supports remoting and not data management, thus it can become a lot of extra work to make sure that clients are in sync and to avoid reloading the model which can be large (especially since lazy loading is not possible).
So it feels like what I'm left with is a situation where I have to treat my Flex application more like a regular old web application where I do a lot of fine grained loading of data.
LiveCycle is too expensive. The free version of WebOrb for Java really only does remoting.
Enter GraniteDS. As far as I can determine, it's the only free solution out there that has many of the data management features of LiveCycle. I've started to go through its documentation a bit and suddenly feel like it's yet another quagmire of framework that I'll have to learn just to get an application running.
So my question(s) to the StackOverflow audience is:
1) do you recommend GraniteDS,
especially if my current Java stack
is Spring + Hibernate?
2) at what point do you feel like it starts to
pay off? That is, at what level of
application complexity do you feel
that using GraniteDS really starts
to make development that much
better? In what ways?
If you're committed to Spring and don't want to introduce Seam then I don't think that Granite DS will give you much beyond Blaze DS. There is a useful utility that ensures only a single instance of any one entity exists in the client at any one time but it's actually pretty easy to do that with a few instances of Dictionary with weak references and some post-processing applied to the server calls. A lot of the other features are Seam-specific as alluded to here in the docs:
http://www.graniteds.org/confluence/display/DOC/6.+Tide+Data+Framework
Generally, the Tide approach is to minimize the amount of code needed to make things work between the client and the server. Its principles are very similar to the ones of JBoss Seam, which is the main reason why the first integration of Tide has been done with this framework. Integrations with Spring and EJB 3 are also available but are a little more limited.
I do however think that Granite's approach to data management is a big improvement over Livecycle's because they are indeed quite different. From the Granite docs:
All client/server interactions are done exclusively by method calls on services exposed by the server, and thus respect transaction boundaries and security defined by the remote services.
This is different to how Livecycle DS uses "managed collections" where you invoke fill() to grab large swathes of data and then invoke commit() methods to persist changes en-mass. This treats the backend like a raw data access API and starts to get complicated (or simply fall apart entirely) when you have fine-grained security requirements. Therefore I think Granite's approach is far more workable.
All data management features (serialization of JPA detached entities, client entity caching, data paging...) work with Spring.
GraniteDS does not mandate anything, you only need Seam if you want to use Seam on the server.
Actually, the free version of WebORB for Java does do data management. I've recently posted a comparison between WebORB for Java, LiveCycle DS, BlazeDS and GraniteDS. You can view this comparison chart here: http://bit.ly/d7RVnJ I'd be interested in your comments and feedback as we want this to be the most comprehensive feature comparison on the web.
Cheers,
Kathleen
Have you looked at the spring-blazeDS integration project?
GraniteDS with Seam Framework, Hibernate and MySql is a very nice combination. What I do is create the database, use seamgen to generate hibernate entities then work from there.
Related
A legacy web application written using PHP and utilizing MySql database needs to be rewritten completely. However, the existing database structure must not be changed at all.
I'm looking for suggestions on which framework would be most suitable for this task? Language candidates are Python, PHP, Ruby and Java.
According to many sources it might be challenging to utilize rails effectively with existing database. Also I have not found a way to automatically generate models out of the database.
With Django it's very easy to generate models automatically. However I'd appreciate first hand experience on its suitability to work with legacy DBs. The database in question contains all kinds of primary keys, including lots of composite keys.
Also I appreciate suggestions of other frameworks worth considering.
Use sqlalchemy. On any framework you choose. It can reflect your database as ORM.
I’m currently rebuilding a legacy PHP web application with a MySQL database my self.
The PHP code was kind of spaghetti and is now rewritten in Java as it type safe, promotes well-structured code, has excellent tooling and has superior unit testing capabilities. For database to Java mapping I use Hibernate/JPA.
The web application is incrementally delivered to production. Meaning we run both Java and large parts of the old PHP code together until the application is fully converted.
But in order to use hibernate effectively we needs the database to be logical correct (something MySQL MyIsam does not enforce). So with each production release I run an refactoring scripts for the database (also used to build the development environment and do unit testing) and update the PHP code with a new version that works with the schema changes.
As a web framework I use Stripes as it’s simple, elegant and easy to learn.
I have very good experience with Django. Every time I needed it was up to the task for interfacing with existing database.
Autogenerated models are the start, as MySQL is not the strictest with its schema. Not that it will not work only that usually some of the db restrictions are held in app itself.
My first thought would be to use Hibernate and Java, but I may be biased because that is what my experience is in. You generally map your Model classes via Hibernate after you create the database anyway, so it might not be a bad choice.
I'll let it explain itself to you: Hibernate's website
I suppose that any PHP Framework (I'm a PHP guy, so I will only talk about PHP) could be OK for you ; but you should use one that's well-supported, has a large community, ...
To make things short, I'm thinking about one off this list :
Symfony
Zend Framework
CakePHP
Kohana
Code Igniter
Now, if you're asking "which framework is the best", it's a question that doesn't really have an answer : it's mainly a matter of personnal preferences...
Still, here's a couple of questions+answers that could bring you some interesting informations :
Best PHP framework for an experienced PHP developer?
What PHP framework would you choose for a new application and why?
To use a PHP framework or not?
PHP Framework Decision - Analysis paralysis!
PHP - MVC framework?
Which PHP Framework is right for this project?
Also, note that choosing a Framework is an important decision -- which means you should take some time to evaluate each framework and how it'll answer your specific need.
Really : you should definitely not rush that decision.
You know, there's a whole Ruby web dev world away from Rails, e.g.:
Sinatra
Ramaze
Webby
With such a general question it's always a bit hard to help...
Try web2py, extremely easy to prototype any webapp, and IMO a bit easier to grasp (overall) than other similar web frameworks, HTH
There are no clear cut winners when picking a web framework. Each platform you mentioned has its benefits and drawbacks (cost of hardware, professional support, community support, etc.). Depending on your time table, project requirements, and available hardware resources you are probably going to need some different answers.Personally, I would start your investigation with a platform where you and your team are most experienced.
Like many of the other posters I can only speak to what I'm actively using now, and in my case it is Java. If Java seems to match your projects requirements, you probably want to go with one of the newer frameworks with an active community. Currently Spring Web MVC, Struts2, and Stripes seem to be fairly popular. These frameworks are mostly, if not totally, independent of the persistence layer, but all integrate well with technologies like hibernate and jpa; although you have to do most, if not all, of the wiring yourself.
If you want to take the Java road there are also pre-built application stacks that take care of most of wiring issues for you. For an example you might want to look at Matt Raible's AppFuse. He has built an extensible starter application with many permutations of popular java technologies.
If you are interested in the JVM as a platform, you may also want to look at complete stack solutions like Grails, or tools that help you build your stack quickly like Spring Roo.
Almost all of the full stack solutions I've seen allow for integration with a legacy database schema. As long as your database is well designed, you should be able to map your tables. The mention of composite keys kind of scares me, but depending on your persistence technology this may or may not be an issue. Hibernate in Java/.NET supports mapping to composite keys, as does GORM in grails (built on hibernate). In almost all cases these mappings are discouraged, but people who build persistence frameworks know you can't always scorch earth and completely recreate your model.
I have just started to work on a Java Based CMS and I am trying to figure out how would my application architecture look like.
To elaborate a bit, I have developed Java EE applications using Hibernate ans Spring and I am now used to thinking in terms of a
Presentation Layer --> Business Layer --> Database Access Layer --> Database
When I look at the CMS, I try to relate this to the Application Architecture of the conventional Web Based Application. I also try to figure out where would Hibernate and Spring integrate into it or would this integration be supported?
In simpler terms, I am unable to perceive a General Architecture of an Application based on a CMS.
Have I made myself clear?
Any Help/Hints/Pointers?
I've never found an elegant solution to this; app builds I've done seem to sit better alongside rather than within CMS-managed content, using similar but copied HTML/JSP templates. Any presentation layer reuse you can get is a bonus!
One particular issue is version control of app source code and DB structure/data, which is obviously A Good Thing. Other site content may not sit within source control (SVN, etc) and you sure as hell don't want to take that risk with your app...
Having said all this, it's perhaps worth making a feature of such separation rather than apologising for it. Base your architecture around it prominently and design for a clean integration.
Here's an explanation of how you can integrate Spring and Hippo CMS (apache licensed Java CMS): http://www.gridshore.nl/2008/07/06/integrate-hippo-cms-into-a-spring-application/.
The architecture of Hippo CMS is explained here: http://www.onehippo.org/about/architecture
Disclaimer: I work for Hippo and this is based on my own experience. There's a big chance there are more solutions out there than the one I'm describing.
you can see this,
Magnolia CMS
Presentation Layer --> Business Layer --> Database Access Layer --> Database looks like a fairly reasonable layering to me. The question this immediately raises is why you have doubts about this. I'd tackle the problem from a different perspective (that usuall helps to shake the brain-cells into action!).
What kind of CMS are you building? In what way does it differ from the many other CMS's? Is there anything about your "unique selling point" that would influence the architecture to be non-standard in some way (if I can put it like that)?
What solutions exist to persist data, without requiring a full-blown enterprise server? I am fairly new to Java. At uni the whole curriculum was based on Java, so I coded a bit already. But it never went into depth with the available frameworks. The only way we actually touched on persistens was using "vanilla" JDBC connections.
I've done some digging around and came across the typical solutions. Most prominently "JAXB", "JPA", "Hibernate" and "TopLink". As far as I can tell, the last two are actually implementing "JPA", which is just a spec. Am I right here?
All the tutorials I have found so far explained these fairly well, and I have to say that I like JPA quite a lot. But all the tutorials I have seen, explained it all using web-pages. I am looking for a swing based solution however. Without webstart or the likes. I'd like to create a stand-alone Java desktop app. Given the target audience and the requirements, I don't need a client/server architecture anyways.
Now, there is also the topic of Beans Binding. Which, to me, looks like fun. Even considering that you have to fire you "PropertyChanged" events manually. Honestly, I don't care about the few added lines.
So... for creating a stand-alone desktop app, saving (and reading) data from already existing legacy databases:
What are your recommendations of frameworks/libraries/specs?
JPA?
JDBC?
Beans Binding?
One more important thing: The primary database I would be writing the app against contains Mutliple Table Inheritance and Slowly Changing Dimensions. I've been doodling around with TopLink already, and the results are fine. But I want to get rid of the application server.
... oh, and... would it be feasible to use Beans Binding in conjunction with Entities? Making the properties read/writable?
I recommend JPA -- while it's a standard, it is completely separate from the whole Java EE spec. You don't need a enterprise application server to use it. In fact, Sun has a "Using JPA in Desktop Applications" article.
JPA + Hibernate, Derby in memory java database, Swing destop App. After annotating my Model classes and specifying the derby driver and such trivia in XML files, persistency was all automagic.
Based the accepted answer to this question I've setup a NetBeans/tomcat environment.
In testing this setup I'm trying to create a Java Web/Web application, but is stumped by the a choice of frameworks for this test-app.
The choices are:
Spring Web MVC 2.5
JavaServer Faces
Struts 1.3.8
Hibernate 3.2.5
In my reading-up (googling & SO) and fairly quickly got lost in the woods, so I am considering just picking one and if it doesn't pan out, to later switch/migrate to a different one. Would such an approach be feasible?
Background on the project
(Must be Java-based due to legacy code)
It uses a self-signed applet to do client-side rendering & interaction;
Servlets retrieve data-sets requested from the client;
Database may be on some remote server, so I intend to use JDBC for accessing it;
The legacy system was CORBA (ACE/TAO) based with lots of C++ modules that need to be translated to Java, and the existing Java-modules (fortunately few) that make CORBA-calls need to be changed to use the newly translated Java-modules.
If you can come up with better approach to handle this project, please tell me.
(This project has all the hallmarks of what I like: it is interesting, challenging, and I learn something new)
Well first of all it can't hurt to take a close look at the whole Spring Framework in general. The documentation is quite good starting at the very basic module working it's way up to the web MVC layer (where you can decide if you want to use it, e.g. Struts Integration is possible, too - but I found Struts always to be a hassle anyway). Hibernate is the probably most popular Object Relation Mapper framework. It is used to store, query and retrieve you Domain Model Objects (everything that you want to store in the database) but doesn't have anything to do with the web layer.
I personally don't like JSF (another specification monster that takes way more time to get into it than it needs to). If you favour a widget based approach (putting you page together with componentes instead of outputting plain old HTML) you might want to have a look at Google Web Toolkit.
Another Spring sollution is GRails. It is really fun to use and even if you have to learn another (scripting) language (called Groovy) you can still use all your Java legacy classe in the Framework because Groovy classes are compatible with Java classes (and vice versa).
And btw. I thought that CORBA is a technology / protocol / standard that especially allows you to access methods and objects independently of the language. Wikipedia:
The Common Object Request Broker
Architecture (CORBA) is a standard
defined by the Object Management Group
(OMG) that enables software components
written in multiple computer languages
and running on multiple computers to
work together, i.e. it supports
multiple platforms.
So why do you have to translate the C++ modules to talk to Java?
First of all, cross Hibernate off your list - while you'd be advised to use it if you've got an ORM requirement it's not related to the web-tier.
Then I think you've two choices:
Spring MVC and JSF
Struts
Heading down either route is going to commit you to that/those API(s) and a switch at a later date is never going to be painless.
My advice would be:
use Spring MVC - you'll likely be using Spring anyway and so it's a natural choice.
ignore JSF, write the HTML yourself, using JSTL to render beans.
use JQuery/JavaScript to enrich the user experience.
use Hibernate for object persistence.
I think it is a good idea to just pick up the minimum, and add as needed. Chances are that you gain simplicity that way.
An idea could be to start with Spring as your "grand scheme of things", and integration technology. Then add complements as needed:
persistence : Hibernate
javaScript : pick a js library that goes well with the Spring MVC module you're using
I am working on medium sized web application 4-5 tabs, user login for about 100k users. We are completing redesigning the application from scratch and using spring and hibernate, connected to MySQL.
Did you experience major issues and what where did Spring benefit your application.
No major issues. Spring was particularly of benefit for:
Making all the configuration plumbing consistent and straightforward
Dependency Injection to support better factoring of code
Declarative "Open Session In View" functionality for Hibernate
Declarative Transaction Demarcation
The Acegi (now Spring Security) project made it easy to integrate a custom security model
The Spring data access support removes the need for a lot of boilerplate from any JDBC access - maybe not such a boost for Hibernate usage, but we had a mix of both. It also allows you to use JDBC & Hibernate together fairly seamlessly
In addition to what has been said so far, I would focus on newer style annotations for both Spring (e.g. #Controller) and Hibernate (e.g. #Entity). It will further reduce your codebase leaving you with less code to maintain. On the downside, there is a pretty significant learning curve, but ultimately the lesson I learn time and again is that the benefits of Spring + Hibernate far outweigh the (learning curve) costs. You simply have to write a lot less code letting you focus on the business.
+1 Spring+hibernate......
100k users is not mid-size....that is huge.
With spring, you can force coder to code to interfaces and this increase testability. This is the benefit i don't hear people talk a lot about.
take a look memcached to cached data memcached.....
techincally speaking I have, I've deployed commercial applications with numbers from the thousands to a few hundreds of thousands using spring, hibernate and both.
From the management perspective in one case, I had a team that were good technologists, so they managed to rewrite an app with spring and hibernate but... they went crazy with the interfaces (each new object to the model needed 16 interfaces), abused the AOP so transactions and logging were almost impossible to follow and stack traces were meaningless, used tools to map the hibernate files without fully understanding what was being done (in some cases joining 4 tables for what could've been a simple entity, and a variety of issues that made the resulting application much harder to enhance, debug, fix, even setup the developer's environment....)
my 2c
As Julien Chastang said, you need to factor in the learning curve in your estimations if this is your first project. We failed to do that on our first try and ended up having to adjust a lot of our planning because several aspects of Hibernate were "hard" (eg. took some time) to figure out.
One specific piece of advice I can give based on an issue we came across is: if you need to write complex SQL, and you don't want to spend the time figuring out how to get such queries working within HQL or other offerings within Hibernate, get it working first in vanilla SQL and then go back later and patch it back into Hibernate.
Obviously there are a million ways to build an application like this, both in the java frameworks world and with things like Rails or Django.
A big selling point for me is that both spring and hibernate have become defacto standards in the java world, so they definitely qualify as "things you ought to know" ( I get asked on every job interview). Spring more so than Hibernate.
Getting the value of spring took a few spring-enabled apps before it made sense for me. It enforces independant code modules and a certain style of component design that facilitates testing. I'd suggest you just go with it and get the sense of the value of it from use.
I have mixed feelings about Hibernate, though it's important to use some kind of db layer, so you may as well.
Also see this question.
There are some situations with Hibernate where creating a particular object to relational mapping, or writing a particular HQL query, is very difficult. However, you're going to run into 1 thing like that out of 10, and the more normalized your database the better off you will be. It's worth it.
Any new Java web project should use Spring MVC (2.5+ with Annotations) and Hibernate.
There is a large understanding overhead to hibernate and spring. I'd only suggest it if you have plenty of time or an experienced java/spring/hibernate developer to call on. With a spring project once you get it going you can basically ignore the spring parts of it and concentrate on page and logic design. Hibernate is not that difficult. HQL is a harder ask. Most of my time is spent at the bean and JSF level. Comparing that layer of my project to some mates who are messing about in JSP, I'm glad to be in the ease of JSF. I easily swapped to Oracle from the initial implementation in MySQL, so that proves that Hibernate handles abstraction nicely.
in addition to what has been said so far, i strongly suggest the book: Spring Recipes - Problem Solution Approach (Amazon), in combination with the very good online documentation you should be ready to conquer the world ;-)