私たちが評価しているアプリケーションは、Oracleデータベースでspringおよびspring mvcを使用して構築されたWebアプリケーションです。これは3層アーキテクチャですか？
ブラウザをクリックするたびにデータベースコールが終了します。
ほとんどのビジネスロジックはデータベースプロシージャ内にあります。
さて、次の3つの層を持っています少なくとも、アプリケーション内のティアの数は正しい。
2番目の点では、これがSOA準拠のアプリケーションであるかどうかは分かりませんが、私はベットしていますが、これはベストプラクティスに従わないという議論を容易にすることができます。私の最初の生まれではない。 SOAはかなり複雑で、10人に15の回答を得ることを尋ねます。しかし、あなたの記述に基づいて、発見可能性、合成可能性、自立性、抽象化、および疎結合の分野でシステムがSOAテストに失敗したと私は言います。そしてあなたがそれをどのように見るかによって、サービス契約も同様に。
これはあなたの質問ですが、あなたの組織はSOAのために何が必要だと思いますか？
あなたが提供した情報は、それが3層かサービス指向かはわかりません。
3層は、通常、UI層/サービス層/データベース層を意味します。それぞれには責任があります。サービス指向アーキテクチャーとは、しばしば、システム内でさまざまな機能を実行するために別々のデプロイ可能なサービスを持つことを意味します。あなたの声明だけではどちらの定義も確認も拒否もしていません。
だから技術的に、あなたの管理がある -
MVCパターンに違反していると思われるものは、複数層パターンのものです。一般的なMVCアプリケーションでは、ビジネスロジックはコントローラーコードに属し、データベースプロシージャーには属しません。ただし、3層アプリケーションでは、一般に3つの層、インタフェース層、ビジネス層、および永続性層が必要です。そして技術的に彼らはそれを持っています。だから、MVCを適切にフォローしていないと主張するべきですし、せいぜい3層アプリケーションが実装されていないことがあります。
また、サービス指向アーキテクチャーを使用していないことを証明するための十分な詳細情報も提供していません（ただし、驚いていますが）。 SOAは、ビジネス・ロジックを構成する論理コンポーネントがどのように結合されているかに関係しています。それらが緩やかに結合されたものであり、異なるプロバイダの実装のために上下にスワップアウトされる場合、それらはSOAを持つでしょう。論理構成要素が大きな破損を引き起こすことなく互いに容易に分離できないような密結合が存在する場合、それらは結合しない。
ほとんどのビジネスロジックがデータベースプロシージャにある場合、はおそらくにはSOAはありませんが、わかりません。残りのビジネスロジックは、実際にこのパターンに従うかもしれません。
私は3つの層のアーキテクチャの評価にはあまりにも厳しいです。今私は訂正した。 UI-BL-Persistanceのための適切なプレースホルダーを持つアプリケーションは、3つのタイヤアプリケーションの対象となります。データベース呼び出しが多すぎる場合は、実装が不良であることを示します。 Wrt SOA私は利用可能な情報が十分ではないことに同意します。すべての回答が私の投票を得て、原則として1つだけを選択するようになる。 –
はい、springとspring-mvcを使用すると3つのレイヤーが可能です。しかし、すべての呼び出しがデータベース呼び出しで終了するので、中間層がプロキシ機能を実行しているように見えます。効果的に私たちはUIレイヤー→プロキシレイヤー[ビジネスレイヤー、データアクセス]→データベースoracle11gを見ています。これは3タイヤの用途にはまだ適していますか？ Wrt SOA私は、複数の定義があることに同意します。 –
まだ複数の層がありますが、中間の統合層は単に完全に活用されていません。特に、ミドルウェアの統合を効果的にサポートできるUIアーキテクチャを使用する場合は、これらの層の細い線です。 J2EEとSpringの前に、すべてのミドルウェアロジックをコントローラサーブレットに組み込んでいました。奇妙なの？しかし、私はあなたのミドルウェア層が実際にオーバーヘッドになっていることをあなたの経営者に議論させることができると思います。 – Perception