1

私は自分のプロジェクトをどのように構成すべきか疑問に思っていました。

他のプロジェクトで (再) 使用されているプロジェクトがいくつかあります。

つまり、私たちのデータ プロジェクトとモデル プロジェクトは、1 対多の他のプロジェクトで使用されます。

私が実際に知っておくべきことは、このタイプのプロジェクトをどのように構築するか、どのように名前を付けるのが最善かということです。

標準の 3 層アプリケーションでは、次のようになります。

  1. DAL、DataAccessLayer、データ...
  2. モデル、ビジネス オブジェクト、BOL ...
  3. UI、ビュー、...

他のアイデアはありますか？

私が働いている各会社では、組織化の方法が異なります。他より優れているものはありますか? どちらを使用し、どちらを好みますか?その理由は?

どうも！

4

5 に答える 5

2

再利用可能なコードをすべて配置しようとするライブラリ プロジェクトがいくつかあることを除けば、それは私がしていることのほとんどです。次に、モデルと DAL をこれらのライブラリの上に置き、プロジェクトの仕様を追加するだけです。

于 2009-02-21T15:24:09.327 に答える
1

データレイヤーには、通常次のものを使用します。

Company.ProjectName.Data (つまり、AdventureWorks.OrderManager.Data)

ビジネス層については、「ObjectModel」のようなものを好みます（「Business」または「BusinessLogic」を使用しましたが、これはデータがオブジェクト/クラスにまとめられる領域なので、そう名付けないでください）。

Company.ProjectName.ObjectModel (つまり、AdventureWorks.OrderManager.ObjectModel)

UIに関しては、昔ながらの「UI」か「プレゼンテーション」のどちらかが好きです...

Company.ProjectName.Presentation (つまり、AdventureWorks.OrderManager.Presentation)

于 2009-02-21T15:47:04.360 に答える
1

ほとんどの場合、Microsoft Patterns & Practices Application Architecture for .NET: Designing Applications and Servicesで推奨されているレイヤード アーキテクチャを使用します。ドキュメントは、それを実装するためのアーキテクチャと .NET テクノロジについて説明しています。

代替テキスト

于 2009-02-21T16:09:07.643 に答える
0

ソフトウェア アーキテクチャは、構築するソフトウェアの種類によって異なります。カーネル プログラミングを行う場合は、アプリケーション開発を行う場合と比較して、他の原則が適用されます。物理シミュレーション、天気予報ソフトウェア、ソフトウェア IDE、またはコンパイラを実行する場合は、さらに別の原則が適用されます。

あなたはアプリケーション開発をしたいと思っていると思います。そうですね、おそらく、反映しようとしているドメインを中心にソフトウェアを設計したいと思うでしょう。しかし、それでも多くのオプションがあります。

この大きなトピックの詳細については、からとから読むことを強くお勧めDomain Driven Designします。Eric EvansApplying Domain-Driven Design and PatternsJimmmy Nilsson

于 2009-02-21T15:39:07.030 に答える
0

私は現在、3 層アーキテクチャを持つフロントエンド Web アプリケーションに取り組んでいます。

  • クライアント層 (ブラウザー)
  • アプリケーション層 (アプリケーションが存在する Java EE アプリケーション サーバー)
  • バックエンド層 (メインフレームとレガシー アプリ、さまざまなデータベース)

階層化されたアーキテクチャがあり、アプリケーション層のレイヤーは次のとおりです。

  • プレゼンテーション層: クライアント層で使用される UI を生成します。
  • アプリケーション層: ユース ケースに相当し、アプリケーション ロジックを含みます
  • サービス層: ドメイン ロジックとデータをバックエンド層から Java モデルにマップします。
  • 統合レイヤー: バックエンド層と通信し、JMS、電子メール、...、DAO などのゲートウェイを含みます

これは単なるプロジェクト構造の例であり、最終的な結果はアプリケーションのタイプによって異なります。パッケージの分割と命名戦略に関するこの質問に対する私の回答で詳細を読むことができます。

必要に応じてレイヤーを追加/交換/削除できます。たとえば、SOA では、アプリケーション レイヤーまたはサービス レイヤーの上に Web サービス レイヤーをレイヤー化して、ESB (エンタープライズ サービス バス) がアプリケーションまたはサービスに接続できるようにすることができます。これらのいずれかが不可能または非常に難しいと思われる場合は、最適なアーキテクチャと設計がありません。

プロジェクトの構造を検討し、上記のようなシナリオを可能にするために、必要なモジュールとコンポーネントのいくつかの重要なプロパティは次のとおりです。

  • テスト容易性
  • 再利用性
  • 保守性

これは、低結合と高凝集性を考慮して設計することで実現できます。機能/抽象化のレベルによってモジュールをグループ化することによって階層化されたアーキテクチャを選択することは、良い出発点です。各レイヤー内で、機能別にさらにグループ化することも役立ちます。より具体的な各層がより一般的な層のインターフェースのみに依存するようにすると、結合も減少します。

于 2009-02-21T15:50:16.083 に答える