命名規則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などのプレフィックスを使用する必要がありますか？プレフィックスを使用するように求めている理由は、ソリューションのクラスがフレームワークの他のクラスと競合していない場合、プレフィックスが各クラスがどこに属しているかを理解しやすいためです？

序文

うまくいけば、これは明白ですが、...以下の提案の名前空間で、あなたが代わるMyCompanyと、MyProjectあなたの会社やプロジェクトの実際の名前を持ちます。

DTO

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

例：Person、Address、Product

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

DAL

ここでの私の個人的な好みは、MyCompany.MyProject.DataAccess名前空間/プロジェクト内で、DTOクラスと一致する1対1のDALクラスのセットを使用することです。ここでのクラス名は、Engine競合を避けるために接尾辞で終わります。（その用語が気に入らない場合、DataAccess接尾辞もうまく機能します。選択したものと一致するだけです。）各クラスは、ほとんどの入力パラメーターと戻り値の型にDTOクラスを使用して、メソッドListからの戻りなど、複数ある場合のジェネリックFind()）。

例：PersonEngine、AddressEngine、ProductEngine

依存関係： MyCompany.MyProject.Models

BAL / BLL

また、ここでは1対1のマッピングですが、MyCompany.MyProject.Logic名前空間/プロジェクト内にあり、クラスにLogic接尾辞が付けられています。これは、DALを呼び出す唯一のレイヤーです。ここのクラスは、多くの場合、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サービスのような舞台裏のユーティリティ）で共有できます。ただし、これは、チーム間の強力なコミュニケーションと徹底的な自動回帰テストが実施されている場合にのみ行ってください!!! そうしないと、あるチームが共有コアコンポーネントを変更すると、別のチームのアプリケーションが破損する可能性があります。

私は通常、アプリケーションを次のように構築します

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にやや似ています。

プレフィックスについては、嫌いです。マイクロソフトの内部コーディングガイドラインもそれらを嫌っています。また、接頭辞についても文句を言うStyleCopというツールがあります。