• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

manipulate DB without Data Access Layer

 
Hendra Kurniawan
Ranch Hand
Posts: 239
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I have an idea where I make a utility class that constructs SQL syntax for data manipulation like so:


and then the business logic will call directly those static methods in the builder class like so


Can anybody point limitation or weakness of this approach? with this approach, no more pesky data access layer. We only need to modify the builder class if database vendor changes, quite convenient (at least to me).
 
Wendy Gibbons
Bartender
Posts: 1111
Eclipse IDE Oracle VI Editor
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
when i have had anything to do with a database layer, it was to save construction time, you know the shape of an insert for invoices so why re-construct the same string every time?
 
Hendra Kurniawan
Ranch Hand
Posts: 239
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
actually the insert will adapt to objects passed into the method. so Book, Employee, CreditMemo will use that same method. The insertStatement method will take care of the rest. so it will work not just for Invoice.

 
Wendy Gibbons
Bartender
Posts: 1111
Eclipse IDE Oracle VI Editor
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
where are you going to get the column names and datatypes from to write the sql statement?
 
Hendra Kurniawan
Ranch Hand
Posts: 239
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
from the object itself of course
 
Jelle Klap
Bartender
Posts: 1952
7
Eclipse IDE Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Are you confident you've found a solution for all of the issues that arise from the object-relational impedance mismatch?
I'm not saying a plain JDBC / native SQL data access approach is an invalid one, and if it fits your needs by all means go for it, but I'd give this some careful thought.
 
Hendra Kurniawan
Ranch Hand
Posts: 239
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
let's say the objects passed won't be too complicated. no inheritance objects involved. Assuming that this is the case, what is the weakness / limitation of this approach. But surely abstraction part has been done nicely right? Thanks
 
Martin Vajsar
Sheriff
Posts: 3752
62
Chrome Netbeans IDE Oracle
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I'd say making the methods non-static, extracting an interface from the class and providing a factory method to obtain concrete implementations would be very very easy and would allow you to support several DB vendors in one package (without a need to shuffle the source code of SQLBuilder around). The factory method can return a singe constant implementation for starters. It's well worth the effort, in my opinion.

Apart from that, having the objects "know" the table name and column names of their attributes mixes the responsibilities a little bit more than necessary, but actually I'm doing something similar in my project.
 
Hendra Kurniawan
Ranch Hand
Posts: 239
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
^
^
why do you suggest to make the methods non-static? wouldn't it be easier so no need for extraneous instantiation? what's the limitation of static?
 
Martin Vajsar
Sheriff
Posts: 3752
62
Chrome Netbeans IDE Oracle
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
That suggestion is based on this sentence:
Hendra Kurniawan wrote:We only need to modify the builder class if database vendor changes, quite convenient (at least to me).

You might well need to support two database vendors during the transition (the old one in the prod environment, the new one in dev/test environments). That would mean to shuffle the builder class code around for builds/deployments to different environments.

The factory method I've suggested would allow you to support both vendors in your code base, and choose the proper implementation at runtime (based on property file created during build, for example, or even dynamically by identifying the vendor of the JDBC driver used). In any case, the logic would be contained in the factory. That is not possible with static methods, of course.
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic