I recently stumbled upon many queries on google about how to make Stored Proc calls via JPA. Something was not right with questions like this.
Stored Procs and JPA are completely different beasts with completely different philosophies behind them. Sure you can call stored procs using JPA but thats using the wrong hammer. JPA deals with persistence of entities; Stored procs, with business logic being closest to the data.
If you have a lot of business logic in stored procs, you have the advantage of speed, security and maintainability, however, you lose portability of your business logic if you change your database. Now, in any large-scale enterprise, the database vendor is not really going to change and a database (oracle/sql server/db2) is going to be a uniform commitment across the organization. Having said that, even if you have to port the procs from one database to another, the vendor documentation will include quite comprehensive migration guides for the same. They have to :) For the record, IMHO, I normally stick with stored procs for the reasons listed above. I always have some real DBA cats working on my team that perform something called ATM (Application Transaction Modelling) on the database. Look it up (ATM). Once they are through with this you can flex your ORM muscles all you like, but in the end what you will be left with will just be UGLY.
:
0 komentar:
Posting Komentar