2

アプリケーションをHR、在庫管理システムなどのさまざまなモジュールに分割するasp.netプロジェクトにモジュール設計を実装しようとしています。さまざまなモジュールを互いに独立させようとしているため、これらのモジュールをそれぞれモジュールは、UI、BLL、DAL、さらには別のデータベース スキーマを備えた別の Visual Studio ソリューションです。

今まで、これは管理システムと ERP を開発するための一般的な方法だと思っていましたが、過去 3 日間 Web を検索しましたが、モジュラー アプリケーションの開発に関する完全なヘルプはほとんど見つかりませんでした。私が見つけたもののほとんどは、結束と結合の概念を説明する単なる理論であり、現実世界のシナリオではありません. だから私は疑問に思う

  1. モジュールを分離するのは正しいアプローチですか？
  2. 実際のモジュラー アプリケーションはどのように開発されるのでしょうか。
  3. さまざまなモジュールが互いにどのように通信する必要がありますが、それらは互いに独立したままです。
  4. これらのモジュールを利用するコア アプリケーションが必要だと思いますが、コア アプリケーションはこれらのモジュールとどのように通信する必要がありますか?
  5. 各モジュールに共通のデータ、エンティティ、オブジェクトがいくつかあります。他のモジュールがそれらを使用できるようにコアモジュールに配置する必要があります(これにより、モジュールがコアに結合されると思います)、またはすべてのモジュールが独自に維持する必要がありますデータのコピー + それらのオブジェクトを定義します (これは DRY を無効にすると思います)

ご意見、リンクは大歓迎です。

4

3 に答える 3

3

これは個人的な意見であり、議論の余地があります。

各モジュールが UI、BLL、DAL、さらには別のデータベース スキーマを持つ別の Visual Studio ソリューションになるように、これらのモジュールを分離しました。

完全にやり過ぎのように聞こえます。抽象化よりも抽象化の方が、アプリケーションの維持、サポート、強化が困難になります。モジュールを個別のソリューションに分割する必要があるほど大きいですか?

モジュールを分離するのは正しいアプローチですか？

いいえ、それは完全なオーバーエンジニアリングだと思います。プロジェクトを使用してモジュールを分離することをお勧めします。個別のソリューションではありません。ソリューションの問題点は、外部の依存関係管理ツールが必要になることです。このツールを導入して後で維持するには、多大な労力が必要です。

実際のモジュラー アプリケーションはどのように開発されるのでしょうか。

抽象化 (インターフェースと抽象クラス) と個別のプロジェクトの使用。

さまざまなモジュールが互いにどのように通信する必要がありますが、それらは互いに独立したままです。

インターフェイス、DI、IOC、TDDを使用して

これらのモジュールを利用するコア アプリケーションが必要だと思いますが、コア アプリケーションはこれらのモジュールとどのように通信する必要がありますか?

Coreモジュールと通信しません。実際、他のプロジェクト/ライブラリに依存しないことが理想的です。これにより、大規模なソリューションでの参照と使用が簡単になります。

各モジュールに共通のデータ、エンティティ、オブジェクトがいくつかあります。他のモジュールがそれらを使用できるようにコアモジュールに配置する必要があります(これにより、モジュールがコアに結合されると思います)、またはすべてのモジュールが独自に維持する必要がありますデータのコピー + それらのオブジェクトを定義します (これは DRY を無効にすると思います)

プロジェクトから単一のコピーを使用することを強くお勧めしCoreます。理由の詳細については、この質問を参照してください。

于 2013-05-01T10:25:58.213 に答える
1

答えるのが遅すぎますが、面白そうです。

さまざまなモジュールを互いに独立させようとしているので、各モジュールが UI、BLL、DAL、さらには個別のデータベース スキーマを持つ個別の Visual Studio ソリューションになるように、これらのモジュールを分離しました。

アプリケーションの規模によって異なります。機能がほとんどない非常に小さく単純なアプリケーションを作成する場合は、組み合わせたアセンブリを使用しても安全です。または、必要に応じて、UI を他のモジュールと分離します。少なくとも、SOC を強調するのに役立ちます。複数のアセンブリの読み込みは、単一のアセンブリよりも遅くなる可能性があることに注意してください。

モジュールを分離するのは正しいアプローチですか？

モジュールの分離には常に欠点があり、マッピングが必要です。これは、一般的にパフォーマンスが低下し (無視できるかもしれませんが、それでも存在します)、開発時間が遅くなることを意味します。アプリケーションが十分に大きく複雑な場合、モジュールごとにモジュラー単体テストを作成できるため、それだけの価値があります。

実際のモジュラー アプリケーションはどのように開発されるのでしょうか。

正確な練習はありませんが、すべての問題には解決策が必要です。単純な電卓アプリケーションには、重いマルチスレッドや依存性注入アーキテクチャは必要ありません。

さまざまなモジュールが互いにどのように通信する必要がありますが、それらは互いに独立したままです。

インターフェイスの使用。後で別の実装にすることができます。たとえば、現在アプリケーションに C# Winform を使用しており、インターフェイスを使用して BLL と通信しています。後で ASP.Net に移行する場合は、実装を変更するだけで、BLL と通信するためのインターフェイスは同じままにします。

これらのモジュールを利用するコア アプリケーションが必要だと思いますが、コア アプリケーションはこれらのモジュールとどのように通信する必要がありますか?

各モジュールに共通のデータ、エンティティ、オブジェクトがいくつかあります。他のモジュールがそれらを使用できるようにコアモジュールに配置する必要があります(これにより、モジュールがコアに結合されると思います)、またはすべてのモジュールが独自に維持する必要がありますデータのコピー + それらのオブジェクトを定義します (これは DRY を無効にすると思います)

従業員などの同じモジュール/データを共有するエンタープライズレベルのアプリケーションだと思います。均一に動作する必要がある場合は、コア レベルで非常に基本的なロジックを提供する必要があります。アプリケーション/実装レベルでは、各要件を満たすために異なる実装が必要になる場合があります。

すべてのビジネス ロジックをコアに統一することを強制しないでください。特定のアプリケーションが別の実装を必要とする場合、コアを構成可能にするのは困難です。

于 2013-05-02T05:41:23.350 に答える