web-dev-qa-db-ja.com

命名規則DAL、BAL、UIレイヤー

次のレイヤーを使用して典型的なWebアプリケーションを開発しています

  1. UIレイヤー（MVC）
  2. ビジネスロジックレイヤー（BAL）
  3. データアクセス層（DAL）

各層には、BALおよびDALを含む独自のDTOオブジェクトがあります。これに関する私の質問は次のとおりです

  1. DALから返されたDTOは、単にBALの対応するDTOに変換され、UIレイヤーに送信されます。 DTOオブジェクトの属性と構造はどちらも同じ場合があります。このようなシナリオでは、中間オブジェクトを含めずに、DALのDTOをUIレイヤーに単に返す方が適切です。

  2. これらのDTOオブジェクトおよび各レイヤーの他のオブジェクトに名前を付けるための最良の方法は何ですか。 DTOName、ServiceNameなどのプレフィックスを使用する必要がありますか？接頭辞を使用するように求めている理由は、ソリューションのクラスがフレームワークの他のクラスと衝突せず、接頭辞を使用すると、各クラスがどこに属しているかを理解しやすくなるためです。

c#designnaming
35
user3631883

序文

うまくいけばこれは明らかですが、以下の推奨される名前空間では、MyCompanyとMyProjectを実際の会社とプロジェクトの名前に置き換えます。

DTO

すべてのレイヤーで同じDTOクラスを使用することをお勧めします。そのようにメンテナンスのポイントが少なくなります。私は通常、それらを同じ名前の独自のVSプロジェクトの_MyCompany.MyProject.Models_名前空間の下に置きます。そして、私は通常、それらが表す実際のエンティティにちなんで名前を付けます。 （理想的には、データベーステーブルも同じ名前を使用しますが、スキーマを少し異なるように設定することが理にかなっている場合があります。）

例：Person、Address、Product

依存関係：なし（標準の.NETまたはヘルパーライブラリ以外）

[〜＃〜]ダル[〜＃〜]

ここでの私の個人的な好みは、DTOクラスと一致する1対1のDALクラスのセットを使用することですが、_MyCompany.MyProject.DataAccess_名前空間/プロジェクトで使用します。ここでのクラス名は、競合を避けるためにEngineサフィックスで終わります。 （この用語が気に入らない場合は、DataAccessサフィックスも問題なく機能します。選択したものと一致するだけです。）各クラスは、ほとんどの入力パラメーターと戻り値の型にDTOクラスを使用して、データベースにアクセスする簡単なCRUDオプションを提供します（ Find()メソッドからの戻り値など、複数のList内にある場合。

例：PersonEngine、AddressEngine、ProductEngine

依存関係：_MyCompany.MyProject.Models_

BAL/BLL

ここでも1対1のマッピングですが、_MyCompany.MyProject.Logic_名前空間/プロジェクト内にあり、クラスにはLogicサフィックスが付けられています。これは、DALを呼び出すonlyレイヤーである必要があります！ここのクラスは、多くの場合、DALへの単純なパススルーですが、ビジネスルールを実装する必要がある場合に、ここがその場所です。

例：PersonLogic、AddressLogic、ProductLogic

依存関係：_MyCompany.MyProject.Models_、_MyCompany.MyProject.DataAccess_

[〜＃〜] api [〜＃〜]

WebサービスAPIレイヤーがある場合は、同じ1対1のアプローチを使用しますが、_MyCompany.MyProject.WebApi_名前空間/プロジェクトで、クラスの接尾辞としてServicesを使用します。 （ASP.NET Web APIを使用している場合を除き、その場合はもちろんControllerサフィックスを代わりに使用します）。

例：PersonServices、AddressServices、ProductServices

依存関係：_MyCompany.MyProject.Models_、_MyCompany.MyProject.Logic_（DALを直接呼び出すことでこれをバイパスしないでください！）

ビジネスロジックの観察

人々がBAL/BLLを省き、代わりにビジネスロジックを他の1つ以上のレイヤーに実装することは、最も理にかなっているところはどこでもますます一般的になっているようです。これを行う場合は、（1）すべてのアプリケーションコードがビジネスロジックを備えたレイヤーを通過すること、および（2）特定のビジネスルールがそれぞれ実装されている場所が明白であり、かつ/または十分に文書化されていることを絶対に確認してください。 疑わしい場合は、自宅で試さないでください。

エンタープライズレベルのアーキテクチャに関する最後の注意

大企業の場合、または同じデータベーステーブルが複数のアプリケーションで共有される他の状況の場合は、MyProjectの部分を上記の名前空間/プロジェクトから除外することをお勧めします。これにより、これらのレイヤーを複数のフロントエンドアプリケーション（およびWindowsサービスなどの舞台裏のユーティリティ）で共有できます。 ただし、これは、強力なチーム間のコミュニケーションと完全な自動リグレッションテストが実施されている場合にのみ実行してください!!!そうでない場合、共有コアコンポーネントに対する1つのチームの変更により、別のチームのアプリケーションが破損する可能性があります。

48
Troy Gizzi

私は通常、アプリケーションを

ProjectName.Core            // "framework"/common stuff
|- Extenders
|- Gravatar.cs

ProjectName.DataProvider    // database provider layer
|- Migrations
|- ApplicationDbContext.cs  // entity framework

ProjectName.Domain          // database objects
|- Post.cs
|- Tag.cs

ProjectName.Services        // validations, database stuff
|- PostService.cs

Sharp-Lite に似ています。

接頭辞については嫌いです。 Microsoftの内部コーディングガイドライン それらも嫌いです。また、同様に接頭辞について文句を言うStyleCopと呼ばれるツールがあります。

7
BrunoLM