2

少し前に、大きなプロジェクト (.NET クラス ライブラリ) を複数の .NET DLL に分割する方がよいかどうか迷ったときに、ここで質問しました。アドバイスは、1 つの大きな DLL を持つことでした。

この DLL は現在、別のプロジェクトで使用されています。他のプロジェクトは少数のクラスしか使用しないため、プロジェクトには未使用のクラスが多数あります。

1 つの DLL を持つというアーキテクチャの観点から見たこの悪い習慣ですか、それとも私がこれを考えすぎているのでしょうか?

4

4 に答える 4

2

小さなプロジェクトであっても、レイヤーをいくつかのプロジェクト/DLL に分割する傾向があります。たとえば、ビジネス層がデータベースと対話する方法がなく、リポジトリ プロジェクトとしか対話できない場合、適切なパスをたどることが保証されます。 .

同じ概念を使用して、基になるクラスを公開せずに、レイヤーからレイヤーへのインターフェイスを公開できます。これは、ある層が別の層のクラスと直接対話することはできず、Ninject などの IoC ライブラリを介して接続されているインターフェイスを使用する必要があるため、コントラクトによってコーディングするのに役立ちます。

プロジェクトが成長するにつれて、複数の開発者がプロ​​ジェクトに取り組んでいる場合は、それらを分けておくとよいでしょう。フロントエンド開発者、サービス開発者、データベース開発者などは、まったく異なるプロジェクトに取り組んでいるため、互いに競合することはありません。

編集

コメントについて：

1) DI を使用して、レイヤー内で引き続きインターフェイスを使用できます。簡単な例は次のとおりです。

public interface IUserManager{}
internal class UserManager : IUserManager{}

public interface ICustomerManager{}
internal class CustomerManager : ICustomerManager {
    private readonly IUserManager _userManager;
    public CustomerManager(IUserManager userManager) {
        // DI library automatically populates this object
        _userManager = userManager;
    }

    void SomeMethod() {
        var user = _userManager.GetUser(42);
    }
}

2) インターフェイスの操作に苦労する場合は、常にインターフェイスを使用し、使用しないという選択肢を自分に与えないでください。例えば：

// Repository project
public interface IUserRepository{}
internal class UserRepository : IRepository{}

IUserRepositoryビジネス プロジェクトは、 ではなくについてのみ知っているUserRepositoryため、直接参照を取得する方法はありません。もう 1 つの方法は、インターフェイスと実装を 2 つの別々のプロジェクトに保持することです。呼び出し元はインターフェイス プロジェクトへの直接参照のみを持ちます。

それはあなたを正直に保ちます。

しかし、インターフェイスを使用する理由がまったくない場合、たとえば、データベースをモックアウトしたり、同じインターフェイスを実装する別のレイヤーに切り替えたりするつもりがない場合は、それらを完全に除外することをお勧めします。なんらかの潜在的なメリットがある場合にのみ、インターフェースを使用してコードを作成してください。そうでない場合は、理由もなく複雑さを増すだけです。

于 2013-09-17T20:55:03.423 に答える
0

難しく考えすぎだよ。DLL に含まれるすべてがロジックである場合、今日の標準では非常に小さなファイルになり、使用されていないクラスはメモリ スペースをまったく占有しません。

また、展開して追跡するファイルが少ない場合は、物事をより整頓できます。

于 2013-09-17T20:48:47.277 に答える