Español English    
Index   Video Demo   Tutorial   Forum (help)   Screenshots  
Reflections Opentoro: Objects, Databases, and the OpenToro's Philosophy'.

In these days, there has been a notable discussion about ORM, RDBMS and ODBMS, with interesting contributions like Ted Neward’s ‘The Vietnam of Computer Science’ and ‘Avoiding the Quagmire’, Gabin’s reply  ‘In defense of the RDBMS’, and the interesting discussions in the TheServerSide.net (and this) and InfoQ forums.

The next OpenToro version (the 5.0) has an interesting new feature: java objects, like previously database tables, can be easily published in the web. So we have wanted to make a reflection about these questions too.

 

Introduction.

OpenToro is a Web Database Publisher, a tool that allows us developing database-driven web applications (with advanced AJAX technology) in an agile and automatic way. Using OpenToro simply means to forget coding countless SQLs and JSPs every time we want to implement a web application with database access.

When we say ‘publishing’ a database in the web, we want to say generating a web interface that let people listing database tables, visualizing records, and generating forms for inserting, modifying and deleting records.

 

An OpenToro application is just a way to perform manipulations on the data in a relational database in a direct way (through the web).

 

You can see OpenToro too like a framework for rapid development of web applications.

 

OpenToro is not a panacea, and is not suitable for all application scenarios.

Usually you are going to use OpenToro in the Views of an application, using its easy tag lib and its XML files.

 

 

OpenToro and java Objects.

à Introduction

Like we have said, OpenToro next release (5.0 version, planned for November 2007) has an interesting new feature: java objects, like previously database tables, can be easily published in the web.

 

Until now OpenToro have not supported a very object oriented programming style for web applications, supporting more a declarative programming style (OpenToro is a complex metadata-reflective architecture piece of software). The reason is very simple: if you want to publish in the web some database tables, and made some CRUD operations (Create, Read, Update and Delete), why do you need to build a complex application?

It has nonsense using an ORM, a lot of classes for the data model, and a big architecture for doing so simple things. An excerpt from Martin Fowler:

 

Costs of a domain model: The primary cost is the awkwardness of mapping to a database, which typically results in a whole layer of O/R mapping. This is worthwhile if you use the powerful OO techniques to organize complex logic.

 

But there are a lot of problems that are naturally developed using a full object oriented data model. Like Martin Fowler says:

 

At its worst business logic can be very complex. Rules and logic describe many different cases and slants of behaviour, and it's this complexity that objects were designed to work with. A Domain Model creates a web of interconnected objects, where each object represents some meaningful individual.

 

OpenToro wants to do the next step, supporting other data container, like java objects, for web publication.

 

à Our Philosophy.

 

In these days, there has been a notable discussion about ORM, RDBMS, and ODBMS.

 

Our philosophy is the next: keep the things simple.

 

We have identified al least 3 development scenarios: