2

私は、主にasp.netで開発されたヘルスケアアプリケーションに取り組んでおり、バックエンドとしてOracle11gを使用しています。現在の状態では、アプリケーションはUI、BLL、DALの3つのレイヤーに分割されています。BLLとDALはクラスライブラリプロジェクトであるため、単一のdllとしてデプロイされます（1つはBLL用、もう1つはDAL用）。最近、ソフトウェアがレビューされ、ソフトウェア全体を個別のモジュールに分割し、それぞれが独自のプロジェクトとデータベース、つまりInventoryUI（asp.net Webアプリケーションプロジェクト、InventoryBLL（クラスライブラリプロジェクト）、InventoryDAL（）などのインベントリモジュールを持つ）を提案しました。クラスライブラリプロジェクト）。すべてのモジュールは、Webサービスを介して相互に通信する個別のデータベースを持つ3つの異なるプロジェクトを取得します。

だから私の質問は

  1. この提案されたアーキテクチャは、私たちが持っているものよりも優れていますか？
  2. BLLとDALに複数のdllを使用する方がよいでしょうか。長所と短所は何ですか。
  3. 1つのアプリケーションに複数のデータベースを用意する方がよいでしょうか。どのように？

リンク、提案は大歓迎です。

4

5 に答える 5

5

モジュールを物理的に分離することの利点は、作業を異なるチーム間で論理的に分割できることです。あなたの場合、在庫に関連するすべてのものを担当する在庫チームがあり、APIを公開し、他のすべてのチームにとって、在庫モジュールの基盤はブラックボックスです。これは、ドメインの複雑さに取り組むための利点です。

不利な点は、プロジェクトが小さい場合、特にプロセス（またはマシン）の障壁を越えるようなことを行う場合、ソフトウェアの開発と展開のプロセスがはるかに複雑になる可能性があることです。

  1. 提案されたアーキテクチャは、特にサイズに関して、プロジェクトのニーズに基づいてより適切な場合があります。いくつかの妥協もより良いアプローチかもしれません-あなたが数十または百のモジュールを持っているかもしれないとわかったら、同様のモジュールを一緒にグループ化することは実際的なアプローチです。

  2. 利用する基本クラスを提供する共通の祖先が存在する限り、ビジネスロジックおよびデータアクセス用の複数のDLLで問題ありません。接続文字列に関して独自の構成を持つ各DALは、非常に悪い場所です。同様に、1つのDALがマッパーパターンを使用し、別のDALがアクティブレコードを使用する場合（両方のパターンが共存できますが）、これらのパターンは基本クラスで提供する必要があります。

  3. RDBMSが複数のスキーマをサポートしていると仮定すると、複数のデータベースに移動する前に、まず複数のスキーマを使用します。データベースの性質が変化すると、複数のデータベースにアクセスします。トランザクション量が多い場合と読み取り量が多い場合（分析）です。モジュール間を移動する必要のあるトランザクションがあり、データベースを物理的に分離している場合、これらのトランザクションの管理は不必要に複雑になる可能性があります。

于 2013-03-14T12:00:27.443 に答える
2

それは完全にあなたのビジネス要件に依存します。

レビューアがSOAの方向を向いていたようです。システムの一部がすべてを停止せずに故障する可能性があるため、分離された物理モジュールに分離すると、ある程度の安全性が得られます。

ただし、アプリケーションを分離すると、製品も複雑になります（特に、単一のビジネストランザクションをコミットするために、複数のモジュールと通信する必要があるシナリオでは）。

于 2013-03-14T11:56:39.583 に答える
2

（クライアントの要件の必要性により）別のアプリケーションを包含することによって2番目のデータベースを継承するプロジェクトに取り組んだので、私はこのルートを支持しませんでした。コードベースが乱雑になり、データベース間でデータを複製する必要があるか、ビジネスロジックが両方のデータベースにアクセスする必要があります（直接またはWebサービス呼び出しなどの他のメカニズムを介して）。問題のケースでは、一方のデータベースがOracleでもう一方のSQL Serverが必要だったため、2つのデータストアをマージすることは大きな頭痛の種でしたが、私が簡単に選択するルートではありません。

別々のデータベースを持つ複数のプロジェクトへの分割を提案していたレビューアによってどのような議論が提起されましたか？ビジネスロジックを機能領域ごとに別々のDLLに分割したい場合でも、なぜ異なるデータベースとDALが必要なのですか？これは、コードベースが本当に巨大であるか、格納されているデータの量が単一のDB内でパフォーマンスの問題を引き起こしていて、データを別々のDBに分割することで軽減できる場合を除いて、複雑さのために複雑さを導入しているようです。この変更に関与する可能性のある作業の量を考えると、なぜそれを行う必要があるのか​​を証明する責任はこの人にあるようです！

于 2013-03-14T11:56:42.887 に答える
2

私がしがちなのは、最初にサブドメインを定義し、それらが機能に基づいて論理的に分割されていることを確認することです。大きすぎず、小さすぎない。各サブドメインは、サービスレイヤー、アプリケーションレイヤー、ドメインレイヤー、インフラストラクチャレイヤーで構成される分離されたソフトウェアになります（ここで説明します）。

これは、それぞれが独自のリポジトリを持っていることも意味しますが、必ずしも個別のデータベースである必要はありません。実際、私は主に1つのデータベースを保持したいのですが、テーブルが属するドメインを識別するために異なるスキーマを使用します。このようにして、テーブル間の制約（スキーマ間）を維持し、データの一貫性を保証できます。

したがって、コードを論理モジュールで構造化することは理にかなっていると思います（実際にはそうする必要があります）が、これが本当に必要でない場合は、データベースを使用してこれを行うことはありません。信頼性。

于 2013-03-14T12:11:47.190 に答える
1

それはすべてあなたの要件に依存します。

将来、物理層を分離する必要がある場合は、これが便利です（各プロジェクトを異なるマシンで実行して、各モジュールを分離することができます）。ただし、これにより、アプリケーション全体のパフォーマンスが低下します。これによって得られる利点は、他のプロジェクトがこれらの個別のプロジェクト/層に独立してアクセスできることです。

私は、データベースを分離することで利益が得られるかどうかについて非常に懐疑的です。将来、各データベースを別のボックスに移動することを計画していますか？そうでない場合は、異なるスキーマを持つ単一のデータベースに固執すると思います。

于 2013-03-14T11:58:38.010 に答える