層構造。それを正しくしてください

Question

私は階層化されたアーキテクチャを正しく作る方法を学びたいと思います。そのためにはアドバイスが必要です。

プロジェクトの例として、ニュースサイトを作成し始めました。私は自分のプロジェクトをレイヤード：

は、それはそれを行うのがベストですか？私はその角度を（ウェブプロジェクトで）行います。

もう1つ。 Dependency Injectionのレイヤーをもう1つ作っていいですか？

Answer 1

BLLはウェブアプリケーションでしか使用できないように聞こえるので、私はNewsWebSite.BLLと呼んでいません。

私はこれが好きです。会社名がContosoの場合：

// This is where you can put all your common code. 
// I do not mean cross cutting concern here. By common I mean if you have 
// some contstants or enums that are shared by all Dlls 
Contoso 

Contoso.Business 
Contoso.Api 
Contoso.WebApp 
Contoso.Data 

// The name of test projects are exactly the same as the name of the 
// assembly but has the word "Tests" at the end 
Contoso.Business.Tests 
Contoso.Api.Tests 

さらに、私が使用しているパスカルケーシングの命名規則を参照してください。この方法でContoso.BLL.SomeClassを処理する必要はありません。

また、Contoso.Business.Testsは、私のContoso.Buiness名前空間に一致する名前空間に存在します。ここでContoso.Business内のクラスである：そのクラスの

public namespace Contoso.Business 
{ 
    public class Foo 
    { 

    } 
} 

テストは、私は（私はDLLの話ではないのです）Contoso.Business.Tests名前空間に入れていないだろう。彼らは同じ名前空間を共有し、私は簡単にそれらを関連付けることができ

// See the namespace here, I am not using Contoso.Business.Tests 
public namespace Contoso.Business 
{ 
    // The name of the class is identical to the name of the class being tested but the word "Tests" appended 
    public class FooTests 
    { 

    } 
} 

その方法：私はこのようなFooをテストしている私のテストクラスになるだろう。

Answer 2

私はしばしばそのアーキテクチャ構造を使用します。同じ状況では、webAPIと角度を意味します。

しかし、プロジェクトのすべてのニーズを考慮して、その次元も考慮する必要があります。例：ビジネスのロジックを管理する必要がない場合は、BLLを使用するだけで関連性がない場合があります。