Is there a viable methodology for using a relational database without an Object-Relational Mapping tool

Question

I'm beginning a small Web development project (maybe 20 tables initially). I would like to use a relational database for transactions, SQL, indexes, etc. I have limited needs for true objects, though.

Although the application will be written in an OO language (Java), most of the domain data work will consist of: 1. Parse JSON and/or HTTP requests from a client. 2. Write the data to the database 3. Answer queries about the data, by executing SQL commands and generating JSON and/or HTTP results.

The domain data won't really do much of anything: There would be little in the way of server-side (domain/persistent) objects collaborating to provide complex behavior. I'm wondering if there is not a principled way to define and work with the data objects that doesn't require turning them into Objects in the traditional OO sense, just so a mapper can turn them into tuples in a table.

My feeling is that if I wing it I will screw it up. I haven't used a non-OO language in ages.

Pointers to papers would be appreciated, as would pointers to tools in the Java space.

Answer 1

There is no reason why you must model each table row as an object..

You can legitimately consider the table, or a set of tables to be the object, and internally represent/reference those tables/rows as appropriate data-structures.

ie.

  Temperature { Location, Date, Celsius }
  Region { Region, Location }

  class WeatherData
  {
      public Decimal regionalMeanTemperature(Region r);
      public Map<Location, MinMax> minMaxByLocation();
      public void add(List<Tuple<Region, Location, Date, Celsius>> measured);
  }

You can certainly make it more object-orientated, but there is nothing wrong about using data-structures internally within an object. I would argue that this is what objects are for, providing a simple interface and common logic to a complex data-structure.

You can even use data-structures on the interface if you take all due caution.

• Do not ever pass out internal data-structures. Copy them or create another object that references them and provides appropriate behaviours for interacting with them.
• Whatever data-structures passed out should be trivially understandable. Tuple<string, string> is not trivially understandable, Tuple<FirstName, LastName> is.
• The data-structure returned must be stable, in that if a binary-tree is returned, it will always return a binary-tree. If you feel that the data-structure might be changed, wrap it in an object.

Answer 2

ORM tools have two general use cases:

1. I don't want to write any SQL myself but want the ORM engine to create any necessary queries.
2. I am dealing with a nontrivial object graph and want to easily load/store these objects from/to a database.

For simple CRUD apps that just take data and stuff it in a database, or read records from a database and display them, ORM is often going to be overkill. The queries are reasonable to write by hand, and I'm not dealing with difficult object graphs.

One (non-OO) pattern to do this is a Data Access Layer. The DAL manages database connections and contains the actual SQL. Other parts of the code just call functions in the DAL. A more sophisticated variant of this is the Repository Pattern, which avoids dependencies from your business logic onto a particular database implementation.

Note that there's a sliding scale between “just write SQL” and “full-on ORM”. Techniques like Repositories do object-relational mapping as well, you're just writing that mapping yourself. Even JDBC will do some mapping, e.g. column values to Java datatypes.

Answer 3

I'm wondering if there is not a principled way to define and work with the data objects that doesn't require turning them into Objects in the traditional OO sense...

Database Stored Procs don't use any OO (thank God). You can create your database layer entirely in Stored Procs and just pass the required parameters with the invocation of the Stored Proc.

I understand some people don't like this approach though. It won't affect performance negatively.

If you are the boss do what you feel comfortable with as long as it is not wrong.