1

職場で古いアプリケーションを書き直そうとしていますが、それを行う方法についてアイデアを得るように言われました。

私の考えは次のとおりです。

アプリケーションは主に Web サイトになるため、MVC を使用します。DI および IoC の POCO エンティティを含む EF。Web アプリと他のクライアントが使用するサービスの WCF。

これまでのところ、アーキテクチャは次のようになっているはずです: - Demo.Web - Demo.Entities - Demo.Services

今、私のアーキテクチャは次のようになります。

名前空間 Demo.Entities

// IEntity.cs
public interface IEntity { }

//User.cs
public virtual long UserId { get; private set; }
public virtual string Name { get; private set; }

public User() { }
public User(long userId, string name)
{
    UserId = userId;
    Name = name;
}

名前空間 Demo.Services

// IService.cs
public interface IService<T> : IDisposable where T : IEntity
{
    List<T> GetList();
}

// UserService.cs
public class UserService : IService<User>
{
    public List<User> GetList()
    {
        return new List<User>(); // Simplicity
    }

    public void Dispose() { }
}

これを使用する必要があるときは、次のようにします。

using(IService<User> service = new UserService())
{
    var q = service.GetList();
}

MVC については、Demo.Models のモデルを使用します。実際のモデルが必要な場合は、MVC アプリケーションのモデル フォルダーにリンクしますが、MVC は私の最後の関心事です。

これまでに 1 つの問題を検出しました。指定されたサービスをインスタンス化しないと、複数のエンティティをクエリできません。明るい面では、自分のデータがどのように処理されているかを完全に制御できます。

実際の質問

もしあれば、これらの機能をサポートするためのアーキテクチャ設計を教えてもらえますか?

4

2 に答える 2

3

私はこことここで説明されている SOLID アーキテクチャの原則の大ファンです。最終的な決定を下す前に、チェックしてスパイクする価値があります。DotNetJunkie は、そう遠くない将来に、これらのパターンを WCF で使用する方法についての別のブログ エントリも投稿する予定です。彼が説明するインターフェイスとパターンは、EF または NHibernate で使用できるように十分に分離されています。

あなたの投稿で私が目にする懸念の 1 つは、IEntity インターフェイスです。基本エンティティー用のインターフェースを用意する必要はないと思います。通常は、抽象基本クラスで十分です (つまり、Layer Supertype パターンを使用します)。すべてのエンティティを単一のインターフェイス コントラクトにサブスクライブさせる理由が見つかりませんでした。

また、あなたの例には依存性注入は見られません。を使用するすべてのコードはusing(IService<User> ctx = new UserService())、インターフェイスと実装に依存しています。MVC またはその他のクライアント コードがインターフェイスにのみ強く依存し、具体的な実装がコントロール コンテナーの反転によって解決/挿入されるようにする必要があります。これは、trailmax が投稿した Onion Architecture で一般的なパターンです。

プロジェクトの「三脚」を持つというあなたのアイデアが好きです。ただし、ソリューション内のプロジェクト数が約 5 プロジェクトを超えないようにしてください (単体テスト プロジェクトを除き、それらはカウントされません)。

これまでに 1 つの問題を検出しました。指定されたサービスをインスタンス化しないと、複数のエンティティを照会することはできません。明るい面では、自分のデータがどのように処理されているかを完全に制御できます。

繰り返しになりますが、これらの問題は、上記の記事で説明されているICommandHandlerand IQueryHandler/パターンを読んで採用することで処理できます。IQueryProcessorサービスをインスタンス化する必要はまったくありません。IQueryProcessorまたはコントローラーにコンストラクターを挿入するだけICommandHandler<TCommand>で、IoC コンテナーに実装を提供させることができます。Handle複数のエンティティをクエリする必要がある操作がある場合は、クエリのメソッドで EF または NHibernate にアクセスするだけで実行できます。

これらのパターンを使用する私のプロジェクトの 1 つの例を次に示します。

MyApp.Domain.csproj

すべてのエンティティ、DotNetJunkie インターフェイス、およびコマンド + クエリの実装を含むクラス ライブラリ。これは、Entity Framework やその他のプロジェクトに依存しません。

MyApp.Impl.csproj

インターフェイスの実装、EF DbContext、IoC コンテナーを含むクラス ライブラリ。これには、ドメイン プロジェクトや EF、IoC ライブラリなどへの依存関係が必要です。

MyApp.Mvc.csproj

MVC プロジェクトは、他の 2 つに依存しています。

これは、Onion Architecture の非常に基本的な例です。

于 2012-08-10T13:10:06.157 に答える
1

Onion Architectureを読んでください。それは基本的にあなたがやっていることです。

最後の部分には、物を置く場所のアイデアを拾うことができるサンプル プロジェクトへのリンクがあります。同じ問題に直面していたとき、それは私を大いに助けてくれました。

于 2012-08-10T13:05:37.037 に答える