2016-10-23 14 views
0

私はASP.NET Coreアプリケーションを開発中です。コントローラをリーンに保つために、ほとんどのデータ操作はViewModelで行われます。すべてが正常に動作します - 二つの問題は、しかし、ControllerContext情報にアクセスすることはできませんViewModelのコントローラデータにアクセスする

  1. のviewmodelsある(または私はそれを取得する方法を見つけ出すことはできません)。たとえば、セッション、ユーザー、その他のコントローラは無料で入手できます。

  2. ViewModelsは依存性注入を受け付けません(やはり、それをどうやって渡すかわかりません)。例えば、私がコンストラクタMyController(ApplicationDbContext db)を持っていれば、私はdbが問題なく渡されます。私はComplexViewModel(ApplicationDbContext db)を持っている場合しかし、私は渡されたnullが得る。もちろん、私は今、私は明示的にViewModelにするコントローラーから要求されるものは何でも渡していますまったく同じservices.AddDbContext<ApplicationDbContext>()スタートアップ

を持っています。しかし、より良い方法があるはずです。

+3

あなたのViewModelsには動作がなく、すべての動作をカスタムサービスに移行することをお勧めします。これはあなたの問題を解決するはずです。 –

答えて

1

ビューモデルは、ビューとアクションメソッド間でデータを転送する単純なPOCOであると考えられています。私はすべてのビジネスロジック(またはデータアクセス)をモデルを表示するために混在させることは悪い考えだと思います。あなたはサービスでそれをすることを検討するかもしれません。あなたはこのサービスをあなたのコントローラに注入することができます。

たとえば、

ヨは、ユーザー情報を取得し、あなたはだからあなたのコントローラが

public class UserController : Controller 
{ 
    private readonly IUserService userService; 
    public UserController(IUserService userService) 
    { 
    this.userService = userService; 
    } 
    public ActionResult Details(int id) 
    { 
    var userDto= this.userService.GetUser(id); 
    return View(userDto); 
    } 
} 

リーン滞在する今、あなたはあなたのデータを照会 UserDataAccessを持っているとすることを注入することができ

public interface IUserService 
{ 
    UserDto GetUser(int id); 
} 
public class UserService : IUserService 
{ 
    IUserDataAccess userDataAccess; 
    public UserService(IUserDataAccess userDataAccess) 
    { 
    this.userDataAccess=userDataAccess; 
    } 
    public UserDto GetUser(int id) 
    { 
    // with this.userDataAccess, get a User and map to UserDto 
    // to do : return something 
    } 
} 

サービスを作成することを検討しますUserServiceクラス。

このアプローチでは、使用しているデータアクセステクノロジはビューモデルにはわかりません。明日あなたがパフォーマンス上の理由でEFを捨て去り、Dapperに切り替えることを決めたら、IUserDataAccessという新しい実装を作成して "DapperUserDataAccess"と呼んでDI設定を使って登録する必要があります。他のコードは変更されていません:)

+0

概念的には、私は同意します。ただし、あらゆるビジネス・アプリケーションの場合と同様に、ビジネス・ロジックとデータ・アクセスには多くの*があります。サービスの作成は不要な重複のように見えます。サンプルを構築するために、サンプルViewModelは顧客、注文履歴に関するデータを取得するが、ユーザーの承認制限に関する情報も必要とする(例は完全に作成されている)「CustomerCreditViewModel」となります。 ViewModel *はこれをすべて実行するのに適しているように見えましたが、今まではうまくいきました。しかしおそらく、このアプローチを再考する時が来ました。 – Felix

+0

私は全く同意しません。 IMHO、私はあなたのビューモデルをデータ/ビジネスロジックと混在させるべきではないと思います。彼らは、痩せたフラットPOCOでなければなりません。あなたのデータへのアクセスについての知識はありません。繰り返しますが、私の個人的な意見ですが、私はあなたにそれを課す権利はありません。あなたはあなたが正しいと思われるものに自由に従うことができます。 – Shyju

+1

Heh - 私はあなたと同意見ではないと思う;)私が言っていたことは、ビジネスロジックをVMに入れておけば、(以前は常駐していたControllersよりも良い)今はサービスに移行する時です。 – Felix

関連する問題