Javaクラス/ EJBのPLSQLを変換するオプションを決定する上で、決定ポイント/要因となるものが何か不思議です。Oracle PL/SQLからJavaクラス/ EJBへの移行を選択する
フロントエンドがPowerBuilderだったPLSQLには、かなりの量のビジネスロジックが実装されています。
アプリケーションをWeb対応にするため、アプリケーションはStruts Frameworkを使用してJava/J2EEに移行されています。
特に、RDBMSが引き続きOracle上にあり、PL/SQLで使用できる専門知識がある場合は、PLSQLをユーザー・インタフェースとともに移行する必要があります。
選択に際して考慮すべき要素は何ですか？
適切なドメイン・モデルの背後にあるPL/SQLを分離できれば問題はないかもしれませんが、レガシー・ビジネス・ロジックがたくさんある場合は、HibernateやTopLinkなどの最新のORMテクノロジを活用することはできませんPL/SQLで使用します。
私が働く私たちの状況は、PL/SQLではビジネスロジックが非常に多く実装されているということです。これは特別な用語です - 「Magical SQL」。レガシー・ビジネス・ロジックの変更には、多くのOracleリソースが必要ないため、時間がかかります。純粋に私たちのシステムをより保守性と機敏性を持たせるために、ロジックをJavaレイヤーに移行しようとしています。
短い答えですが、それは賢明かもしれません（私の意見では） - 状況に明らかに依存していると述べるように修正しました。
「ひどく実装された」と何かを証明することができます。開発者がセットベースの操作の重要性を理解していなかったので、驚くほど実装されたORMがRBARベースでデータのゴブを取得するところで、何層の中間層が出現しましたか？または、データベース内のクエリをフィルタリングする方法は？ – APC
@APC私はRDBMSをしっかり信じていますが、私たちの特別なケースでは、それは深刻な虐待を受けており、私たちはそれによってメンテナンスの悪夢に座っています。これまで取り組んでいた従来のシステムには、非常によく書かれた一貫性のある分離されたDBレイヤーが含まれていました。すごく良かった。しかし、時にはそれを中間層に抽出することは、2つのゾウムシの少ないものです。私は、実際にインスタンスに依存していると言いたいと思います。 – mcfinnigan
あなたの状況は明らかにOPとはかなり異なっています。だからあなたの経験に基づいてそれらにアドバイスすることは間違っています。それで、私はこの問題を非建設的なものにすることに投票したのです – APC
「ISはRDBMSがOracleであり続けると PLSQLで利用可能な専門知識がある特別なとき、あまりにもユーザー インターフェースとともにPLSQLを移行する必要があります。」
だけでなく、完全にお勧めできません。
（おそらく）動作するPL/SQL APIがあります。あなたはそれを理解し、それを維持するスキルを持っている人々がいます。なぜそれをJavaに移したいのですかビジネス上のメリットはありません
Javaでフロントエンドを書くだけで十分な楽しみがあるはずです。まず、アプリケーションの他のレイヤーに関する決定を下す前に、その作業を開始してください。
最終的な考え：PL/SQL開発者がいる：代わりにApexにWebフロントエンドを開発してみませんか？
事実上イデオロギー的な2つの視点があります。中間層のビジネスルールまたはデータベースのビジネスルール。明確な正解または間違った答えはなく、実際には特定の状況に依存します。しかし、これは議論を生み出すことができる話題（そしてそれを古いもの）なので、私はこの問題を非構成的に終わらせることに投票しています。 – APC