CODEWITHSUNDEEP
c#asp.net-mvcentity-framework
CesarCarrillo
CesarCarrillo

Reputation: 157

Using a DbContext variable from one Controller to Another

Hi I am using MVC 4 and C# to develop an application that has two controllers: The first one is called Business, it has a method called Create that calls a method called CreatePartner from another Controller named PartnerController.

public class BusinessController : Controller
{
   private storeContext db = new storeContext();

   public ActionResult Create(Business business)
  {
      //Some stuff here

      PartnerController pt = new PartnerController();
      pt.CreatePartner(int partner_id);

      //Here is another stuff that uses db DbContext variable
      return RedirectToAction("Index");
  }
}

This is the second controller Called Partner

public class PartnerController : Controller
{
   private storeContext db = new storeContext();

   public void CreatePartner(int partner_id)
  {
      //Some interesting stuff
  }
}

Each controllers has its Dispose() method

The Problem is: After I called the CreatePartnet method from Business controller I try to use the db variable again to save other data but it throws me the following exception:

 The operation can not be completed because the DbContext has been disposed

-What is the best way to Use methods from one controller to another that has the same DbContext variable name?.

-Something strange happens: My stuff works locally but when I publish my code in the IIS server is when the app throws that exception.

Thanks!

Upvotes: 3

Views: 1730

Answers (1)

Rowan Freeman
Rowan Freeman

Reputation: 16358

Might I suggest an alternative approach?

Controllers are not very good places for business logic; that is they're not very good places for "doing stuff". It's often demonstrated in MVC tutorials and examples in this manner but it's really only good for getting into MVC quickly - it's not very good practice.

Furthermore Controllers aren't really supposed to have methods to be called - from themselves or called from another Controller. Controllers should really just contain their Actions.

Instead, extract your logic to an external class. A Service is a design pattern in which commonly used business logic is abstracted away. That way things can have a reference to the service and execute the logic without knowing anything about the implementation.

Observe:

IPartnerService

public interface IPartnerService
{
    void CreatePartner(int partnerId);
}

DefaultPartnerService

public class DefaultPartnerService : IPartnerService
{
    private StoreContext db;

    public DefaultPartnerService()
    {
        db = new StoreContext();
    }

    public void CreatePartner(int partnerId)
    {
        // Something interesting
    }
}

BusinessController

public class BusinessController : Controller
{
    private IPartnerService _partnerService;

    public BusinessController()
    {
        _partnerService = new DefaultPartnerService();
    }

    public ActionResult Create(Business business)
    {
        _partnerService.CreatePartner(business.PartnerId);
        return RedirectToAction("Index");
    }

}

Of course this approach is also greatly simplified for educational purposes. It's not best practice yet, but it might put you on the right track. Eventually you'll discover problems with this approach and you'll gravitate to reading about Repositories, Unit of Work, Dependency Injection and so on.

Upvotes: 6

Related Questions