Persistence And Automatic Mapping (A-O/RM)

254 9 0 Apr 25, 2009 6:26 PM dabuTech dabu

DDL (Data Definition Language) is the language used to create the database and schema and includes statements like: create, alter, drop, etc. DML (data manipulation language) is the language used to manipulate the data in a database and it includes statements like: select, insert, update, delete, etc. To most of us, it's all SQL, but there actually is a distinction. DDL is about database structure, and DML is about data.

RDB Persistence software (ORMs) quite often generate DDL statements for the database being used. Most of the XML/annotation definition required by persistence software actually exists to support DDL, and to a largely unnecessary extent it exists for the object-relational mapping. Since most shops have database departments and developers who actually design and create the database structures in the database, the DDL that resides in the application software mostly goes unused in that regard. The majority of effort in using persistence software is in the mapping definition itself and this alone is extremely expensive, both for the developers and for the quality of software. Therefore, DDL in the application software is largely a duplication of concerns.

With DDL in the application software, developers are forced to play an annoying game of keeping the object-relational mapping in sync with the changes made to the database and are constantly having to tweak the definitions to mirror the actual schema they are working with. Most of the complaints about today's software development reside around the large amount of configuration developers have to deal with. It has long been known by system administrators that most of the problems they face exist in software configuration, so why would that be any different for developers? It isn't! Projects with large amounts of configuration also have a large number of problems. We should be limiting configuration in software development, but we seem to be increasing it.

Another result and/or side effect of DDL in the application software is the fact that a large part of the database's functionality is made irrelevant and/or is greatly reduced in use, as programmers try to avoid using database functionality that they can't also define in the application's software mapping. The result of all this is inconsistencies between the DDL in the software and the DDL that actually exists in the schema, not to mention the grand extent of effort required to define the object-relational mapping to the application software. Obviously, this causes numerous errors and unexpected results, and is actually completely unnecessary.

So for a typical project, DDL should be defined separately and outside the application, while DML should be soft-coded within the application software. Furthermore, persistence software does not need DDL definitions to handle object-relational mapping. Persistence software can get all the information needed about the structure of an existing database from the database metadata. The ideal situation would have DDL being the concern of the the database experts (data modelers, database developers, and DBAs) and the DML would be the concern of the application developers.

Tags dabuTech

Introducing jWebApp

346 27 0 Jul 27, 2007 10:02 AM dabuTech dabu

jWebApp is a trouble free full featured MVC web application framework that truly removes the complexities of web development and its need for configuration. jWebApp is so simple it can actually be learned in a matter of minutes. jWebApp is specifically designed to satisfy the need for simpler web development.

jWebApp provides support for all of the features you expect from a web development framework, but does not need tag libraries or extensive APIs to implement them. This allows jWebApp to actually attain the separation of concerns and allows independence in model and view technologies. You can use any model/business layer technologies, any database-access technologies, any view-rendering technologies, and plain old HTML and HTML forms (or what ever you like).

jWebApp Features:

• An extremely easy web application framework
• Full stack web development
• Model-View-Controller architecture
• Incredibly easy server side AJAX support
• Full support for RESTful web services
• Simple configuration free web applications
• Easy-to-use URL to object mapping
• Extremely small learning curve (learn in minutes)
• All the functionality offered by other frameworks and more
• No proprietary tag libraries and no need for any
• Use JSP/JSTL, Velocity, or whatever you like
• Use regular HTML and Forms
• Optionally use any BSF compatible scripting language
• Extensive validation support for your data
• Easily handle forwarding, redirects, and non-secure connections
• Easily handle SSL(https)
• Role level security
• Container- and application-based authentication
• Built-in URL rewriting for handling cookie-limited browsers
• Multipart forms and file uploads
• Email with attachments and HTML
• Backend direct payment processing
• Support for regular expression matching
• Secure file downloading and uploading
• and tons more (with jCommonTk, jWebTk and JPersist)

jWebApp also comes with jPersist, which is an extremely powerful, object-relational database persistence API that manages to avoid the need for configuration and annotation; POJO mapping is automatic. jPersist uses JDBC and can work with any relational database and any type of connection resource.

jWebApp and jPersist make web development as easy as defining a simple Java class:

public class Customer extends RequestHandler
  {
    public String processGetCustomer(ServerInterface serverInterface) 
      {
        String customerId = serverInterface.getParameter("customerId");
        Customer customer = jpersist.loadObject(new Customer(customerId));

        serverInterface.setAttribute("customer", customer);
        
        return "/WEB-INF/customer.jsp";
      }
  } 

and creating a view with plain HTML and your favorite template markup (JSP, Velocity, etc):

<div align="center">
    <h3>Customer ${customer.firstName}, ${customer.lastName}</h3>
...
</div>

and then calling:

http://host/context/customer/getCustomer?customerId=jsmith

The following servlet configuration is all that is needed:

<servlet>
    <servlet-name>jwaRequestServlet</servlet-name>
    <servlet-class>jwebapp.RequestServlet</servlet-class>
</servlet>

<servlet-mapping>
    <servlet-name>jwaRequestServlet</servlet-name>
    <url-pattern>/customer/*</url-pattern>
</servlet-mapping>

That's it! No other XML, annotation, or configuration is needed!

You may also have noticed that jWebApp is naturally RESTful. With jWebApp, you can use the same configuration and annotation free URI mapping controller to handle REST based web services using any of the HTTP verbs that are used with REST (GET, HEAD, PUT, POST, DELETE, OPTIONS). jWebApp also supports a more formal REST mode by extending RestfulHandler and implementing the HTTP verbs. Either way, you are RESTful.

Tags Agile, AJAX, dabuTech, Framework, Java, jWebApp, RAD, REST, RESTful, Software Sensation, URL Mapping, Validation, Web Development

Introducing jPersist

328 37 0 Jul 24, 2007 10:06 AM dabuTech dabu

jPersist is an extremely powerful object-relational persistence API with automatic mapping that is based on the Active-Record and Data-Mapper patterns. jPersist wraps JDBC functionality and can work with any relational database, and any type of connection resource, including: java.sql.DriverManager, JNDI, javax.sql.DataSource, and third party connection pooling libraries (DBCP, C3PO, etc.). jPersist uses information obtained from the database (DatabaseMetaData) to handle mapping between the database and Java objects, so mapping configuration and annotation are not needed; in fact, there is no configuration needed at all.

Using jPersist is as simple as:

public void DatabaseExample(DatabaseManager dbm) throws JPersistException
  {
    // Inserting contact with associations
    Contact contact = new Contact("deisenhower", ...);

    contact.getSupport().add(new Support("Request", ...));
    contact.getSupport().add(new Support("Response", ...));
    contact.getSupport().add(new Support("Request", ...));

    contact.getOrders().add(new Order("Dwight D. Eisenhower Dollar", ...));
    contact.getOrders().add(new Order("Susan B. Anthony Dollar", ...));

    // Saving within an automatic transaction (covers all relationships)
    dbm.saveObject(contact);

    // Load based on information contained in classes
    contact = dbm.loadObject(Contact.class, "where :contactId like ?", "tjef%");
    System.out.println("\ncontactId = " + contact.getContactId());

    // Load a collection of objects from the database
    Collection<Contact> c = dbm.loadObjects(new Vector<Contact>(), Contact.class);

    for (Contact contact2 : c)
      System.out.println("contactId = " + contact2.getContactId());
  }

jPersist includes support for efficient use of prepared statements and batch updates. With jPersist you can now do the following:

// Inserting contacts - efficiently uses a single prepared statement
db.saveObject(new Contact("contact0", ...));
db.saveObject(new Contact("contact1", ...));
db.saveObject(new Contact("contact2", ...));
db.saveObject(new Contact("contact3", ...));
db.saveObject(new Contact("contact4", ...));

/**
 * Inserting contacts - uses batch updating
 * and efficiently uses a single prepared statement
 */
db.beginBatch();

db.saveObject(new Contact("contact5", ...));
db.saveObject(new Contact("contact6", ...));
db.saveObject(new Contact("contact7", ...));
db.saveObject(new Contact("contact8", ...));
db.saveObject(new Contact("contact9", ...));

db.executeBatch();
db.endBatch();

/**
 * The following are equivalent to the above.
 */

// Inserting contacts - efficiently uses a single prepared statement
new UpdateManager(dbm) 
  {
    public void run() throws JPersistException 
      {
        for (int i = 10; i < 500; i++)
          saveObject(new Contact("contact" + i, ...));
      }
  }.executeUpdates();

/**
 * Inserting contacts - uses batch updating
 * and efficiently uses a single prepared statement
 */
new UpdateManager(dbm) 
  {
    public void run() throws JPersistException 
      {
        for (int i = 501; i < 1000; i++)
          saveObject(new Contact("contact" + i, ...));
      }
  }.executeBatchUpdates();

jPersist Features:

• Object-relational persistence API
• A Java implementation of the active-record and data-mapper patterns
• Mapping is automatic, there is no configuration, or annotation required
• Objects are isolated from database changes, and vice versa
• Optionally provides simple annotation/functional support for mapping
• Full Support for MySQL, DB2, Oracle, Derby, HSQL, PostgreSQL, H2, and more
• Object-oriented queries, inserts, updates, deletes and more
• All JDBC functionality is supported at some level
• Intermix objects with SQL, and use object properties in SQL fragments
• Full support for database transactions (automatic and manual)
• Automatically handles inheritance via table joins
• Also supports single table inheritance and concrete table inheritance
• Easily handles associations with single instance, arrays, and collections
• Supports any JDBC source including DriverManager, JNDI, and DataSource
• Support for third-party connection pooling (DBCP, C3PO, etc.)
• No SQL required for queries, inserts, updates, deletes
• Uses JDBC with access to underlying connection, statement and result set
• Access stored procedures and prepared statements with the same object-oriented functionality
• Full support for batch updates
• Implements ListIterator and Iterable for object-oriented iteration through data
• Tracks object persistence for inserting and updating
• Can be cast to an interface for database proxying
• Multiple utilities for loading data into collections and maps
• and more

All in all, jPersist's sole reason for being is to provide simple trouble-free POJO oriented access to your database. With jPersist and your POJOs, you should rarely have to do anything more than:

Define a POJO (optionally extending jpersist.PersistentObject), which can be extended by other POJOs (relational hierarchy via joins). Call one of jpersist.DatabaseManager's: loadObject(), saveObject(), and deleteObject(), or one of jpersist.Database's: saveObject(), deleteObject(), and queryObject() with jpersist.Result's loadObject(). Group saves and deletes in a transaction using jpersist.TransactionManager or use jpersist.Database's transaction oriented methods. Group updates in an update manager using jpersist.UpdateManager or use jpersist.Database's update and batch oriented methods. That's not to say you won't have other JDBC needs, like calling stored procedures or executing SQL statements, but with jPersist it's all easy to handle.

Tags Active Record, Agile, Association, dabuTech, Data Mapper, Framework, Inheritance, Java, jPersist, Object Mapping, ORM, AORM, Persistence, RAD, Software Sensation, Transactions