Is it best practice

[Harish Shivaraj]

Hi all.

Im asking things,because im not sure if this is a best practice or how would you do it?

I have a database called Vehicle and query the database using JDBC. I have wrapper around the JDBC library such that every time i do a select on the table it return me a list of object with each object corresponds to a row in the table.

I mean this

Table - Vehicle

Select method

public ArrayList<Vechile> Select(...) { .. }

Would you do it this way or would you just return the ResultsSet? I found it much neater when ? I return the Vehicle object where each row data is content within an object.

Thanks

[Carey Brown]

It is "neater" which should give you an indication that you are headed in the right direction. It is also "object oriented", which SQL by itself, is not.

[Anton Golovin]

Harish Shivaraj wrote:Hi all.

Im asking things,because im not sure if this is a best practice or how would you do it?

I have a database called Vehicle and query the database using JDBC. I have wrapper around the JDBC library such that every time i do a select on the table it return me a list of object with each object corresponds to a row in the table.

I mean this

Table - Vehicle

Select method

public ArrayList<Vechile> Select(...) { .. }

Would you do it this way or would you just return the ResultsSet? I found it much neater when ? I return the Vehicle object where each row data is content within an object.

Thanks

Hi, Harish,

So you found the ORM concept which parses the ResultSet for you and which puts data into objects and returns the objects to you.

This is much more convenient, but not without its pitfalls.

For example, in raw SQL you will have not only direct selects, but joins and sometimes queries that should calculate data on the fly before returning it to you. I am just giving you some hints about using ORM correctly because if you use it to get array on entities mapped to single tables, and you need to do joins, you will find yourself bringing that data into the code and transforming it there - not a performant way to work with ORM.

So, multi-table entity mapping and custom entity types to the rescue (including using stored procedures as supported). Even if now it does not tell you much, as you progress in your skills with ORM, keep it in mind.

ORM is very convenient but you must model it to your schema very carefully to keep your application performant.

With best regards,

Anton.

[Harish Shivaraj]

Thanks very much guys. And thanks for ORM tip will certainly take a look into it.

[Tim Holloway]

Anton Golovin wrote:[
For example, in raw SQL you will have not only direct selects, but joins and sometimes queries that should calculate data on the fly before returning it to you. I am just giving you some hints about using ORM correctly because if you use it to get array on entities mapped to single tables, and you need to do joins, you will find yourself bringing that data into the code and transforming it there - not a performant way to work with ORM.

I'm not sure I understand what that meant. JPA ORMs are popular in large part because they generate optimal SQL JOINs internally, then return the results according to the Entity models you have defined - typically with either 2 classes related via single-item or collection references, or as a composite class synthesized from the join. Meaning that the programmer doesn't have to struggle with the ugly warts of SQL joins because the ORM does it for him/her/it/other.

Taking the results of a JDBC query (ResultSet), constructing per-row entity objects and assembling the together into a collection is manually doing what ORMs do automatically, but ORMs are much, much bigger than just that. And while ORMs are generally preferred over raw JDBC in large, complex production systems, it might be a bit much to deal with while still at the "Beginning Java" level.

So congratulate yourself on your insightfulness, Harish! You're heading in the right direction.

[Harish Shivaraj]

Thanks very much. One things im finding it difficult is this. That every time I change the table specification I need to change a lot things in my code. And I see huge maintenance problem down the line.

The trick im missing here is database schema in java. Which I dont think ive never understood how to do it. What I have right now is SQLBuilder library which I use to build the SQL query statements. It works reasonably well. I still have to hard code complex queries.

Could you point out to good tutorial or provide with the sample code, as to how you go about creating a schema and using them? I would greatly appreciate you help.

Thanks very much

[Junilu Lacar]

Harish Shivaraj wrote:Thanks very much. One things im finding it difficult is this. That every time I change the table specification I need to change a lot things in my code. And I see huge maintenance problem down the line.

This sounds like a lack of layering and abstraction in your application design. A Data Access layer defines interfaces that insulate other layers of the application from details about the underlying data store. Your main application logic should be programmed to the interfaces in the Data Access layer. This way, changes to the implementation details of data access do not ripple out as much to the main application logic.

[Anton Golovin]

Hi, Tim, I meant it is not difficult to mis-use ORM technology in terms of the underlying relational paradigm. What you are writing is using the technology correctly via multi-table entities, etc., in the first place.

If used correctly (i.e., approximating how you would use raw SQL), ORM is very powerful. But if not used correctly...

With best regards,

Anton.