tag:blogger.com,1999:blog-13000143.post7542989752166578553..comments2023-11-05T00:48:20.985-07:00Comments on Radio Free Tooting: Data Access Layer vs Table APIs APChttp://www.blogger.com/profile/18348719053445885097noreply@blogger.comBlogger3125tag:blogger.com,1999:blog-13000143.post-65564035645779782572018-01-04T11:13:45.191-08:002018-01-04T11:13:45.191-08:00Agree.
I'd add that there is also a reduction...Agree.<br /><br />I'd add that there is also a reduction in unintended consequences. Direct DB processing generated from/by an app (Hibernate, anyone?), either natively or through a table API, opens a greater possibility for code with unreliable performance profiles. Breaking into logical units of work prevents (or at least reduces) the possibility that whatever trickles down to the database engine is Bad.<br /><br />Moreover, functional units in the database are more likely to be reused across applications to reproduce rule-based functionality. I may have many clients that want to update or report inventory, potentially written in different languages, from receiving systems, BOM/assembly, public facing commerce, internal customer service, shipping, inventory management, etc. I have to define the same rules individually in each client with a table API, and update them individually when they change. A functional/logical API distills that to one place—the database—and prevents the back-and-forth we often see in transactional systems. It protects data from inconsistencies in the application of changes in client software and reduces effort, with fewer people required to update a single PL/SQL package than the upstream alternative that necessitates multiple client teams writing Java, .Net, C#, etc. to simultaneously coordinate code releases on multiple systems.Seanhttps://www.blogger.com/profile/11687123626547072957noreply@blogger.comtag:blogger.com,1999:blog-13000143.post-79229028260367366762018-01-02T04:43:01.416-08:002018-01-02T04:43:01.416-08:00Also in the "agreed" camp, with all the ...Also in the "agreed" camp, with all the issues raised in this article.<br /><br />The TAPIs I generate in my applications do solve most of these problems, however:<br /><br />1. They only encapsulate all DML (inserts, updates, deletes, merges) - queries are always done via direct queries or (preferably) views.<br /><br />2. The generated code is only a starting point. I add more methods to handle specific requirements, such as bulk inserts, updates, deletes, etc.<br /><br />3. There is a tight coupling between a TAPI and its table, this is intentional. Application code, however, usually calls a Transaction API (XAPI) which translates a requirement into one or more calls to TAPIs.<br /><br />My preferred method has been accused of not being a "true" TAPI and I don't really care :)<br /><br />Just my 2c.Jeffrey Kemphttps://www.blogger.com/profile/04255101699328756710noreply@blogger.comtag:blogger.com,1999:blog-13000143.post-82488319057812141202018-01-01T10:43:55.792-08:002018-01-01T10:43:55.792-08:00I agree. Mark Farnham calls this "Logical Uni...I agree. Mark Farnham calls this "Logical Units of Work", which I like the sound of. I've never likes table APIs. I've always fallen in the Tom Kyte camp of APIs for business functions. What's more, this style of APIs will typically work really well when they are exposed as RESTful web services using ORDS, which solves two problems. You have a great API layer for Oracle-centric apps, and a great RESTful web service API for non-Oracle-centric apps. Boom! :)<br /><br />Cheers<br /><br />Tim...Tim...https://www.blogger.com/profile/17721555946005999179noreply@blogger.com