0

I have read a lot of about IoC and design patterns but I´m not able to find clear answer. I´m doing whole data management in model, so I´m also creating database context in the model, but I found a solution from Benjamin Gale - When should I create a new DbContext(), which I like and it solves me a loft of problems with sharing db context, but my question is, how to pass this context from controller to model? When I have ActionResult like this: 

    [Authorize, HttpPost]
    public ActionResult AccountEditation(AccountEditationModel accountEditation)
    { ... }

Would be good solution to apply setter injection in AccountEditation actionResult, thats mean in each of actionResult method: 

    [Authorize, HttpPost]
    public ActionResult AccountEditation(AccountEditationModel accountEditation)
    { 
    accountEditation.db = Database; //Database from BaseController
    ... 
    }

Or is there any other way to do that?

Community
  • 1
  • 1
Lukas
  • 60
  • 2
  • 12
  • 1
    Your models (also called ViewModels) should be simple data-containers, and should not require a context. If you need methods to load or save data using a context, do not add that in the view-model, but create in a separate class. Some call that a Service, others call that a Model (which is obviously not the same as a ViewModel). See [link](http://stackoverflow.com/questions/20323713/how-to-use-viewmodels-in-asp-net-mvc). – Maarten Nov 11 '15 at 14:50

2 Answers2

3

Despite the name, ASP.NET MVC only loosely follows the MVC pattern. Namely, there's no true Model. Instead, your Model will be a combination of your entity, view models that represent that entity and your DAL, but each of these should be a separate thing. It's totally inappropriate to create or even inject a context into an entity class.

Your DAL will be the sole owner of the context. You should have an interface that represents an API that your application can use. Then, you should have one or more implementations of that interface, one per each discreet data access method (Entity Framework, Web Api, etc.). You'll then inject your context into this implementation and inject the implementation into your controller(s). The controllers, themselves, should only ever reference the interface. This is what's called the provider pattern, and it allows you sub-in different access methods as needed. Decided that you'd rather use Dapper than Entity Framework? Just create a new implementation for Dapper and inject that instead; none of the rest of your code needs to change.

Chris Pratt
  • 232,153
  • 36
  • 385
  • 444
  • Do you have any reference material or example links that can help those relatively new to MVC with implementing such a pattern? – khargoosh Jun 22 '22 at 01:41
0

The easiest thing I have found is to inject a repository into the Controller via Unity. And then pass the repository, if you need to, to whatever service or class you're using to process your business logic.

Basically...

public class AccountController : Controller
{
   private IRepository<Account> _accountRepository;

   public AccountController(IRepository<Account> accountRepository)
   {
      this._accountRepository = accountRepository;
   }
}

When you use Unity and set it up properly, you can automatically inject whatever repository you're using into the AccountController class. After that, you shouldn't have a problem passing that same repository to other services or classes that need it.

Unity Dependency Injection

Safari137
  • 351
  • 3
  • 10