ストアドプロシージャベースのソリューションをOOPに移行しますか？

Question

最近私が参加した私の会社では、ASP.netソリューションを使用して、クライアントにhttpベースのRESTful APIを提供しています。

実際には、この「APIレイヤー」レイヤーは非常に「薄い」もので、パラメータの変換+深いレイヤーの呼び出しという2行のコードしか含まれていない多くのメソッドがあります。

したがって、「APIレイヤー」は、http呼び出しを介して取得されたパラメーターを次のレイヤーに渡します。プロパティーは、プロパティーを主に持つクラス（主にロジックなし）である「ビジネスオブジェクト」に変換されます。この「ビジネスレイヤー」はプロパティをもう一度「リポジトリレイヤー」に渡し、別のクラス（「パラメータクラス」）のプロパティを満たし、最終的にこれらのパラメータでストアドプロシージャを呼び出します。

ほとんどすべての "ビジネスロジック"はストアドプロシージャでは "非表示"になっています。

呼び出されると、out-parametersがC＃リポジトリのレイヤクラスに渡され、すべてのバックが「APIレイヤー」に変換されます。

要するに、C＃クラスは実際にはロジックやOOPを使用しません。実際には、ストアド・プロシージャのパラメータから自動的に作成される可能性が最も高いのは、APIパラメータを収集し、データベース（Oracle）に渡してストアド・プロシージャに渡し、ストアド・プロシージャ・コールの結果をAPI。

前述の「アーキテクチャ」からわかるように、現時点では単体テストと統合テストは存在しません。

説明されたアーキテクチャはかなり古く、私は80年代にはデータベース内のすべてのBLを作成する意味があると思います。

私はTDDに慣れていたので、テスト容易性のために設計されていないため、既存のコードベースの単体テストを作成し始めました。残念なことに、「正しい」ストアドプロシージャが「正しい」パラメータで呼び出されていることから、それほどテストすることもあまりありませんでした。

将来的には、ストアドプロシージャを使用してデータベースにアクセスすることが唯一の方法である必要があるため、ある種のO/Rマッパーに移動することができない可能性があります。

この「アーキテクチャ」についてどう思いますか？

これは（有用な）コードと似ていないので、これまでの私のキャリアで見てきました。私はOOPのメカニズム、SOLIDコード、パターンを使用して、C＃クラスにビジネスロジックを書いて、TDDに使用されています（前バージョン1.0以降のプログラミングのC＃、C++）

...

データベースは、通常は「持続ましたO/Rマッパーを使用してアクセスされた「レイヤー」のみです。

どこから始めたらよいかわかりません。この80年代の "アーキテクチャ"をよりOOPスタイルに変換するにはどうしたらいいですか？

私は現代的なOOPプログラミングスタイルを適用して、メンテナンス可能な自動テスト可能かつ適応可能なソリューションを作成し、ストアプロシージャにロジックを入れ続け、C＃をラッパーとしてこれらのプロシージャを呼び出すのではなく、

Entity Frameworkを使用して基本的なCRUDとクエリ操作を行うストアドプロシージャを呼び出すプロトタイプを作成できますか？

Answer 1

ご返信ありがとうございます！ 私は、物事が努力を必要とするとすぐに、常に「ビジネス価値」が利益である必要があることに完全に同意します。

"大きな古い安定性"アプリケーションの問題は、新しい機能が必要であり、常に（ストアドプロシージャで）追加されていますが、コードの多くは既にそれが本当に何を知らない誰もが古いです。また、新しい機能を追加すると既存の「安定したアプリケーション」が破損する可能性があるかどうかは誰にも分かりません。

"安定性"は必須条件です。私の意見では不幸なことではありませんし、テストを追加せずに機能後に機能を追加すると、さらに悪化します。

少なくとも私の経験と私は、これがコードベースに起こったプロジェクトで働いています。私たちは最近、テストをしておらず、良い実践について知らなかった。実際、3年後には、コードベース全体を捨てて、最初から始めなければならなかった...そしてそう、2回目は良い事例を学び、それをTDD方法で行い、コードベースはまだ新しい要件を追加するのに十分な適応性がある、6年後に。

私はすでに「難しい方法」を学びました。なぜ、テスト可能で適応性のあるコードベースが重要で、私と私のチームがこのやり方をやり直す必要はないのですか？ :)