Announcement

Collapse
No announcement yet.
X
  • Filter
  • Time
Clear All
new posts

    SmartGWTEE datasource SQL or Hibernate

    Hi there,

    i m currently evaluating SmartGWTEE, and found the DataSource in SmartGWT is really good.

    As i have developed a project with GwtExt + Spring + iBatis, in which i used RPC to for data transfer between server and client, it was horrible that i had to have the same bunch of JavaBeans on both sides, a slight change to the database must be applied to both server side beans and client side beans, sometimes a typo may cause big problems.

    I've been trying SmartGwt for 3 days, i really like the way of putting all queries in the .ds.xml files and invoke whatever needed for the client side. SQL changes can be applied just by refreshing the browser! On the other hand, SmartGwt provides three types of DataSource, SQL, Hibernate, and Custom, i m wondering whether i can get rid of the iBatis + Spring on the server side, and use pure SQL DataSource, isn't it more convenient and quicker?

    How do you guys think, does this way ruin the MVC structure (i think SmartGWT defines a perfect MVC by nature, right?)? What is the advantage of using Hibernate or other Object Relational framework in the SmartGWT development over the SQL DataSource? And if i go with the SQL datasource, am i able to switch to Hibernate or iBatis later easily?

    I m starting a new project now, everything can be decided and changed at this stage, your help is much appreciated!

    Thanks!

    #2
    Personally, I would go with straight SQL. You can still add custom java objects to inject business rules where needed and you avoid another layer of software that must be maintained and reduce the overall build complexity.

    Since the DataSource is generic as far as the client is concerned, changing one or more to use Hibernate or iBatis in the future should be relatively straightforward.

    Comment


      #3
      Originally posted by davidj6
      Personally, I would go with straight SQL. You can still add custom java objects to inject business rules where needed and you avoid another layer of software that must be maintained and reduce the overall build complexity.

      Since the DataSource is generic as far as the client is concerned, changing one or more to use Hibernate or iBatis in the future should be relatively straightforward.
      Thanks David, as you said, i think it's not a bad idea to start with SQL for now, and decide whether to use ORM later when i know more about SmartGwt.

      Comment

      Working...
      X