0

私の状況では、私の会社は多くのタイプの顧客にサービスを提供しています。ほとんどすべてのお客様が独自のビジネス ロジックを必要としています。もちろん、すべてのビジネス ロジックが継承する基本レイヤーがあります。ただし、すべての顧客に対して 1 つの DLL を使用するか、顧客ごとに 1 つの DLL を使用するかのいずれかで、これを設計する作業を行ったり来たりしています。

私の最大の争点は、ソフトウェアのアップグレードです。当社には 20 社の企業と連携する約 12 人のデータ入力担当者がおり、ダウンタイムがほとんどないことが重要です。私の懸念は、すべてを 1 つの dll に展開すると、会社 B のロジックを更新するだけで、会社 A のロジックにバグが発生する可能性があることです。各会社のロジックに独自の dll があれば、リスクを軽減できると思います。そのため、会社 A に害を与えることなく、会社 B の更新を展開できます。-- これをサポートするのは私だけです。

とはいえ、これは 20 の異なる .dll を管理するのも悪夢のように思えます。これは BLL だけの場合です。View レイヤーと ViewModel レイヤーも作成する必要があります。したがって、潜在的に、20 (会社) * 3 (レイヤー) を持つことができ、これは 60 の .dll に相当します。

ありがとうございました。

4

1 に答える 1

0

「顧客第一」の場合、ある顧客のコードのバグが別の顧客に影響を与える可能性を減らす必要があります。したがって、より多くの DLL。ビジネス ロジック、ビュー レイヤー、ビューモデル レイヤーを別々のアセンブリに分離する必要は本当にあるのでしょうか。確かに、メンテナンスのためにコードをさまざまなレイヤーに分離したいのですが、論理的なファイルの分離を物理的なアセンブリ/DLL の分離にする強い理由はありますか?

于 2010-06-16T16:07:29.040 に答える