4

Webサイトでアプリケーションのアーキテクチャを最適化していたときに、最善の解決策がわからないという問題が発生しました。

現在、この構造に基づく小さなdllがあります。

Database <-> DAL <-> BLL

Dalはビジネスオブジェクトを使用してBLLに渡し、BLLはこのdllを使用するアプリケーションに渡します。

BLLのみが公開されているため、このdllを含むすべてのアプリケーションがbllを表示できます。

当初、これは当社にとって良い解決策でした。しかし、そのDLLにますます多くのアプリケーションを追加すると、Bllは大きくなります。現在、一部のアプリケーションが他のアプリケーションからBll-logicを認識できるようにしたくありません。

今、私はそのための最良の解決策が何であるかわかりません。

私が最初に考えたのは、bllをアプリケーションに含めることができる他のdllに移動して分離することでした。ただし、他のdllがデータを取得できるように、Dalを公開する必要があります...そして、私は良い解決策のようです。

私の他の解決策は、bllを異なる名前空間に分離し、アプリケーションに必要な名前空間のみを含めることです。ただし、このソリューションでは、必要に応じて他のbllに直接アクセスできます。

だから私はあなたの意見を求めています。

4

4 に答える 4

4

ビジネスの「セグメント」ごとに個別のBLLとDALを用意する必要があります...例：

  • MyCompany.HumanResources.BLL
  • MyCompany.Insurance.BLL
  • MyCompany.Accounting.BLL
于 2010-05-11T14:32:07.323 に答える
3

@MikeCに同意します。セグメントごとに、名前空間でBLLを分離します。また、次のようにDALも分離します。

  • MyCompany.HumanResources.DAL
  • MyCompany.Insurance.DAL

もう1つ行うことは、dllを分離することです。このように、DALを公開する必要はありません。これは、システムごとにBLLとDALを担当するビジネスレイヤー（WCFやWebサービスなど）になり、サポートとメンテナンスがより簡単になります。現時点で（複雑さの点で）あなたの会社にとって最も手頃なアプローチかどうかはわかりませんが、設計目的にはより良いアプローチです。

以前、ここで会社で開発されたアプリケーションは、コンポーネントアーキテクチャを使用し、アプリケーションを介してコンポーネントを共有していました。私たちは、それが最良の設計ではなく、今日、多くのシステム（実稼働環境）がその設計アプローチを使用していることに気づきました。

さらに、より複雑なものが必要な場合は、接続、コマンド、およびトランザクションを制御する操作を含む、データアクセスの維持を担当する汎用dbHelperコンポーネントを生成することもできます。このようにして、コードの書き直しを防ぎます。そのアセンブリは、エンタープライズライブラリまたはその他のコンポーネントを利用できます。操作例は次のとおりです。

public DbCommand CreateCommand()
    {
        if (this._baseCommand.Transaction != null)
        {
            DbCommand command = this._baseConnection.CreateCommand();
            command.Transaction = this._baseCommand.Transaction;
            return command;
        }
        return this._baseConnection.CreateCommand();
    }

SqlCommand CreateCommandなどを実装して、仮想化することができます。

覚えておいてください：私が公開した一般的なdbHelperのアイデアは、単なるアイデアです！

于 2010-05-11T15:05:23.020 に答える
2

ビジネスロジックをそのパーテントに応じて（以前の投稿に従って）異なるdllに分割することをお勧めします。これらのクラスは特定のインターフェイスを実装し、このインターフェイスはビジネスログインコンシューマーで宣言されます。次に、dllの実装を解決するためにコンテナを実装することをお勧めします（制御の反転理論を参照）。これにより、ビジネスロジックの実装を消費から分離でき、一部の実装を問題なく別の実装に置き換えることができます。

私は、ビジネスマネージャークラスを直接消費するのではなく、IoCでプロバイダーの使用を擁護します（悪夢につながる可能性のある参照について考えてください）。このソリューションは、dllの分離とそれらの最適化された消費の問題を解決します。

于 2010-05-11T15:05:16.337 に答える
2

組織全体に適用される共通のビジネスロジックと、セクションまたは部門ごとのより具体的なロジックがあるようです。各部門がそうなるようにコードを設定することができます。舞台裏で「基本」ロジックの一般的な機能を使用する特定のロジックにのみ依存します。そのために、次のプロジェクトを設定できます。

  • Business.BLL
  • Business.Finance.BLL
  • Business.IT.BLL
  • （etc、ad infinitumなど...）

これらはそれぞれ、独自のアセンブリにコンパイルされる個別のプロジェクトである可能性があることに注意してください。部門は、独自のアセンブリを使用するだけで済みます。

データアクセスに関する限り、ベースBLLに汎用データアクセスルーチンを含めることができます。特定のBLLは、ベースBLLにファネルされた独自の特殊なデータクエリを持つことができます。ベースBLLは、汎用DALを使用して、結果をチェーンに戻します。

于 2010-05-12T19:32:09.420 に答える