steve | 
10 26th, 2005| 
I have invited discussion of DCAF on the AJUG mailing list, and below is a reply to a question that adds to the knowledgebase of DCAF.
Its been many long years now, finding time between work and being the only hands on the project doesn’t allow it to move that fast. I guess its been ready to show to the world for over a year now, but just havn’t had the time to get everything together and actually show it off.
More detail on DCAF, ok let me start with the basics.
DCAF maps data sources (not only RDBMS) to ‘entities’ each of these entities is a complex class that extend the BaseDO. This approach differs from other persistance engines in that all of the persistance logic is accessible via the entity itself. Ie with just a User entity you can persist the data, refresh the data or even locate related objects.
There are 4 layers to DCAF, the Persistance layer, the entity layer, the business layer and the List layer.
The perisistance layer is configured to which dialect of SQL or which data source to connect to, DCAF has focused on ORACLE, Mckoi, MySql and MSSQL.
All of the syntacic logic for each system is included with the base DCAF product.
The entity layer is an automatically generated layer (using DCAFg) driven by a config file. This layer is the end classes used by the developer to access the data source. Each entity maps onto a specific table and has cool features like read locking for transaction committing.
The business layer is another automatically generated layer that models the business relationships between the data source entities. This layer is again automatically generated using DCAFg. So you might have a Customer entity that has Orders, to access the orders you would get the Customer then invoke getOrdersCount() to see how many orders exist, or getOrder(int i) to get a specific order.
The list layer is the 3rd auto generated layer. This layer replaces the need for SQL and acts as a container for business objects. Code like the following would show you the orders for delivery in the future.
OrderList list = new OrderList();
list.addSearchField(OrderList.DELIVER_DATE, BindVariable.CONSTRAINT_GREATER_THAN, new Date()));
list.loadEntries();
By NOT using SQL I have found that changes to the database are much easily managed, as there are compile time constraints on the bind columns allowing what once were major changes to happen easily.
I hope that gives a bit more of an idea of the structure, as for what I think the benefits are.
Simple Devloper Access
I really find that when using DCAF a developer doesn’t really even know they are accessing a data source. The code above for loading orders doesn’t require SQL knowledge or even that there is a data source. It reduces accessing the data source to a series of simple Java commands. Lets say u need to update user 123′s last name to “Smith” the code would be the following.
User user = new User(123);
user.setLastName("Smith");
user.save();
All of the logic for loading the entity updating the column and committing the transaction is done automagically, no need to understand transactions etc..
Business Relationships
Most persistance engines that I’ve looked at (tho not in depth) stop at the entity level. You can read and write data from a table, but you then still need to understand the relationships between the tables and how to load them. DCAF allows you to configure this in the XML file and autogenerate the relationships. Then using lazy loading allow you access to these related objects with a single method call.
Transaction Management
All save calls are wrapped in Transactions, but more to that, as there are
business relationships a save to a top level element will persist all
changes to related objects. So there may be a User table and an
UserPreference table, we could modify some UserPref’s and/or add some new
ones, then with a simple user.save(); call not only would any changes to the
user be saved, but also the UserPref changes. The newly added user prefs
would be automatically populated with the foreign key details from the user,
all done seemlessly to the developer.
I havn’t had a heap of experience with other persistance engines like
Hibernate. I started working on DCAF over 6 years ago (as part of a uni
project) and its evolved to where it is today. I did see hibernate come,
and tried it but never long enough to know it in and out. But from what I
have read DCAF does all the core function hibernate does, but does it in a
different fashion that I think makes data access simpler.
This is the type of discussion I was hoping to start, so please feel free to
ask any/all questions.. I know that code speaks louder than words, so I’m
hoping to get an example app up onto my site in the next day or so.