PeterとModikaには完全に同意しますが、いくつか追加したいと思います。
アプリを設計するときは、それらを別々のプロジェクトに入れる理由を理解し、関心の分離を完全に理解する必要があります。つまり、何を分離しているのか、なぜそれを心配しているのかを知る必要があります。
私はその特定の本を読んだことがないので、著者のアプローチについてコメントはありません。とにかく、作者が物事に名前を付けた方法が「プロの」方法であると信じる前に、アプリケーションだけでなく、.netフレームワーク自体のようなものがどのように構成されているかを考えてください。
特定のプロジェクトでは、データアクセスコード、オブジェクトモデル、UI、ビジネスロジックなど、いくつかの種類のアーティファクトを作成する必要がある場合があります。
いくつかの自然な境界領域があります。たとえば、永続ストレージオプションを交換する必要がある場合や、LINQ、NHibernateなどのアクセス方法を交換する必要がある場合に備えて、データアクセスコードを分離する必要があります。
オブジェクトモデルを他のソリューションで再利用できるようにしたい場合があります。または、WebFormsからMVCへの移動などのUI部分の交換をサポートしたい場合もあります。オブジェクトモデルの使用方法や使用者に応じて、オブジェクトモデルに異なるビジネスロジックを適用する必要がある場合もあります。
とはいえ、すべてのアプリケーションに同じ構造上のニーズがあるわけではありません。たとえば、オブジェクトモデルは、ビジネスロジックがないと完全に無意味になる可能性があります。または、より可能性が高いのは、クラス定義と絶対にマージする必要がある特定のロジックがあり、他のロジックはライブラリの使用方法に固有である可能性があります。前者の場合は、クラス定義とまったく同じプロジェクト/アセンブリにビジネスロジックを配置する強い理由があります。後者の場合は、他のアセンブリに分離して、オブジェクトのインターフェイス定義を実装することをお勧めします。
私の経験では、わからない場合は一緒に保管してください。状況に応じて後で必要なものをリファクタリングすることを目的とした最も簡単なオプションだからです。
早い段階でオーバーエンジニアリングを行うと、プロジェクトの時間/コストが増加し、後で実現することのない潜在的なメリットが認識されます。これが良い決断になることはめったにありません。さらに、将来何が必要になるかわからないという問題もあります。今すぐ分離すると、今日のプロジェクト時間が長くなり、後でリファクタリングする必要があります。これは二重の問題です。真にプロの開発者であるIMHOは、潜在的なソリューションを評価する際に、コスト/開発時間を考慮に入れています。
ここで、他のプロジェクトで再利用される可能性が高いカスタムビルドのメンバーシッププロバイダーに関する特定の要件に到達します。カスタムプロバイダーは、独自のプロジェクトと名前空間に含まれている必要があります。おそらく、のような名前空間を使用しますCompany.Security。これにより、移植性の最良の方法が提供され、この1つのプロジェクトに固有の他のあらゆる種類のものに沿ってドラッグすることなく、関連するコードだけを再利用できます。
プロバイダーモデルを使用しているため、これを直接参照する必要のあるコードを他のプロジェクトに含めることはできません。すでに存在するインターフェースを使用するだけです。