Comment by 'Guest' on 2006-08-07 04:13:24 The new kids driven by hype around ORM products like Hibernate tried them. The old Java developers were always using JDBC. JDBC 4.0 is good news. Although a simplification of the exception handling mechanism would have been great.
|
Comment by 'Guest' on 2006-08-07 10:32:57 Why not use Object relational mapping tools if it is obviously simpler than using any version of JDBC ? |
Comment by 'Guest' on 2006-08-10 00:26:21 I think there is two big categories of application in the real world: - "entity-based" application You define a clear set of entities for your application and use them for all your operation - "data-centric" application you split you code in one logic layer and one data access layer, but your data access layer manipulate the tables directly, not alway passing through an entity representation. My opinion is that "data-centric" is actually the way most application are coded. As an example consider the typical sceniario below: You have customer and order tables and you need to display in a grid each customer and its # of orders. - in "entity-based" application you simply load all the customers. They will have a property with the list of orders. What you need populate the grid by iterating over the list of customers and getting the size of the order list for each customer. - in "data-centric" application, most of the time, you will have a query in your access layer such as "select c.name, count(o) from customer c inner join order o on c.id = o.customer_id group by c.name" The result of this query can not be mapped to an entity, if you want to use the result you will need do one of the following: - bind the ResultSet to the grid - load the ResultSet into some disconnected structure for later usage (DataSet, XML, or other structure) Both solution can lead to clean, well-defined application. It all depends on your needs. In "data-centric" application, it is often hard to know what are the data structure that are passed across the tiers (Array for "single column select", XML, DataSet, Custom classes) because they may vary. In "entity-based" application, other problems may appear: performance, partial entity loading, complex database structure... My final word will be about database independance: JDBC provides some database independent syntax ("escape syntax") that is very usefull. If you want to achieve database independent (or less dependent) solution consider this + some custom code in your data access layer before immediately chosing an OR mapping tool.
|