Develop Reference

LifetimeManager in Builder Strategy

I want to implement a disposing transient lifetime manager for Unity version 3.5. The problem is that I don't know how to access the LifetimeManager in the PostTearDown,etc. steps of the BuilderStrategy class. context.Lifetime works fine in Unity 2.
Basically I have the following:
Container = new UnityContainer();
Container.AddNewExtension<DisposableStrategyExtension>();
Container.RegisterType<ITest, Test>(new DisposingTransientLifetimeManager());
public class DisposingLifetimeStrategy : BuilderStrategy
{
public override void PreBuildUp(IBuilderContext context)
{
base.PreBuildUp(context);
// context.Lifetime.Count == 0 here and in all other methods.
// In version 2 of unity this is set.
}
// implement rest of methods, but context.Lifetime.Count is 0 in all of them too.
public class DisposingTransientLifetimeManager : LifetimeManager
// implement abstract methods minimally

You can get the lifetime manager from the policy list:
public class DisposingLifetimeStrategy : BuilderStrategy
{
public override void PreBuildUp(IBuilderContext context)
{
ILifetimePolicy lifeTime = context.Policies.Get<ILifetimePolicy>(context.BuildKey);
base.PreBuildUp(context);
}
public override void PreTearDown(IBuilderContext context)
{
// Assumes registration name is null
var buildKey = new NamedTypeBuildKey(context.Existing.GetType());
ILifetimePolicy lifeTime = context.Policies.Get<ILifetimePolicy>(buildKey);
base.PreTearDown(context);
}
}
If you are calling IUnityContainer.Teardown(obj) then the PreTearDown and PostTearDown methods will not know the name of the resolved object. That may not matter as long as a default (null) registration exists (since I assume you just want to cast the object to an IDisposable and then Dispose the object).

Using Simple Injector with Unit Of Work & Repository Pattern in Windows Form

I'm trying to implement IoC in my windows form application. My choice fell on Simple Injector, because it's fast and lightweight. I also implement unit of work and repository pattern in my apps. Here is the structure:
DbContext:
public class MemberContext : DbContext
{
public MemberContext()
: base("Name=MemberContext")
{ }
public DbSet<Member> Members { get; set; }
protected override void OnModelCreating(DbModelBuilder modelBuilder)
{
base.OnModelCreating(modelBuilder);
modelBuilder.Conventions.Remove<PluralizingTableNameConvention>();\
}
}
Model:
public class Member
{
public int MemberID { get; set; }
public string Name { get; set; }
}
GenericRepository:
public abstract class GenericRepository<TEntity> : IGenericRepository<TEntity>
where TEntity : class
{
internal DbContext context;
internal DbSet<TEntity> dbSet;
public GenericRepository(DbContext context)
{
this.context = context;
this.dbSet = context.Set<TEntity>();
}
public virtual void Insert(TEntity entity)
{
dbSet.Add(entity);
}
}
MemberRepository:
public class MemberRepository : GenericRepository<Member>, IMemberRepository
{
public MemberRepository(DbContext context)
: base(context)
{ }
}
UnitOfWork:
public class UnitOfWork : IUnitOfWork
{
public DbContext context;
public UnitOfWork(DbContext context)
{
this.context = context;
}
public void SaveChanges()
{
context.SaveChanges();
}
private bool disposed = false;
protected virtual void Dispose(bool disposing)
{
if (!this.disposed)
{
if (disposing)
{
context.Dispose();
}
}
this.disposed = true;
}
public void Dispose()
{
Dispose(true);
GC.SuppressFinalize(this);
}
}
MemberService:
public class MemberService : IMemberService
{
private readonly IUnitOfWork unitOfWork;
private readonly IMemberRepository memberRepository;
public MemberService(IUnitOfWork unitOfWork, IMemberRepository memberRepository)
{
this.unitOfWork = unitOfWork;
this.memberRepository = memberRepository;
}
public void Save(Member member)
{
Save(new List<Member> { member });
}
public void Save(List<Member> members)
{
members.ForEach(m =>
{
if (m.MemberID == default(int))
{
memberRepository.Insert(m);
}
});
unitOfWork.SaveChanges();
}
}
In Member Form I only add a textbox to input member name and a button to save to database. This is the code in member form:
frmMember:
public partial class frmMember : Form
{
private readonly IMemberService memberService;
public frmMember(IMemberService memberService)
{
InitializeComponent();
this.memberService = memberService;
}
private void btnSave_Click(object sender, EventArgs e)
{
Member member = new Member();
member.Name = txtName.Text;
memberService.Save(member);
}
}
I implement the SimpleInjector (refer to http://simpleinjector.readthedocs.org/en/latest/windowsformsintegration.html) in Program.cs as seen in the code below:
static class Program
{
private static Container container;
[STAThread]
static void Main()
{
Application.EnableVisualStyles();
Application.SetCompatibleTextRenderingDefault(false);
Bootstrap();
Application.Run(new frmMember((MemberService)container.GetInstance(typeof(IMemberService))));
}
private static void Bootstrap()
{
container = new Container();
container.RegisterSingle<IMemberRepository, MemberRepository>();
container.Register<IMemberService, MemberService>();
container.Register<DbContext, MemberContext>();
container.Register<IUnitOfWork, UnitOfWork>();
container.Verify();
}
}
When I run the program and add a member, it doesn't save to database. If I changed container.Register to container.RegisterSingle, it will save to database. From the documentation, RegisterSingle will make my class to be a Singleton. I can't using RegisterLifeTimeScope because it will generate an error
"The registered delegate for type IMemberService threw an exception. The IUnitOfWork is registered as 'Lifetime Scope' lifestyle, but the instance is requested outside the context of a Lifetime Scope"
1) How to use SimpleInjector in Windows Form with UnitOfWork & Repository pattern?
2) Do I implement the patterns correctly?

The problem you have is the difference in lifestyles between your service, repository, unitofwork and dbcontext.
Because the MemberRepository has a Singleton lifestyle, Simple Injector will create one instance which will be reused for the duration of the application, which could be days, even weeks or months with a WinForms application. The direct consequence from registering the MemberRepository as Singleton is that all dependencies of this class will become Singletons as well, no matter what lifestyle is used in the registration. This is a common problem called Captive Dependency.
As a side note: The diagnostic services of Simple Injector are able to spot this configuration mistake and will show/throw a Potential Lifestyle Mismatch warning.
So the MemberRepository is Singleton and has one and the same DbContext throughout the application lifetime. But the UnitOfWork, which has a dependency also on DbContext will receive a different instance of the DbContext, because the registration for DbContext is Transient. This context will, in your example, never save the newly created Member because this DbContext does not have any newly created Member, the member is created in a different DbContext.
When you change the registration of DbContext to RegisterSingleton it will start working, because now every service, class or whatever depending on DbContext will get the same instance.
But this is certainly not the solution because having one DbContext for the lifetime of the application will get you into trouble, as you probably already know. This is explained in great detail in this post.
The solution you need is using a Scoped instance of the DbContext, which you already tried. You are missing some information on how to use the lifetime scope feature of Simple Injector (and most of the other containers out there). When using a Scoped lifestyle there must be an active scope as the exception message clearly states. Starting a lifetime scope is pretty simple:
using (ThreadScopedLifestyle.BeginScope(container))
{
// all instances resolved within this scope
// with a ThreadScopedLifestyleLifestyle
// will be the same instance
}
You can read in detail here.
Changing the registrations to:
var container = new Container();
container.Options.DefaultScopedLifestyle = new ThreadScopedLifestyle();
container.Register<IMemberRepository, MemberRepository>(Lifestyle.Scoped);
container.Register<IMemberService, MemberService>(Lifestyle.Scoped);
container.Register<DbContext, MemberContext>(Lifestyle.Scoped);
container.Register<IUnitOfWork, UnitOfWork>(Lifestyle.Scoped);
and changing the code from btnSaveClick() to:
private void btnSave_Click(object sender, EventArgs e)
{
Member member = new Member();
member.Name = txtName.Text;
using (ThreadScopedLifestyle.BeginScope(container))
{
var memberService = container.GetInstance<IMemberService>();
memberService.Save(member);
}
}
is basically what you need.
But we have now introduced a new problem. We are now using the Service Locator anti pattern to get a Scoped instance of the IMemberService implementation. Therefore we need some infrastructural object which will handle this for us as a Cross-Cutting Concern in the application. A Decorator is a perfect way to implement this. See also here. This will look like:
public class ThreadScopedMemberServiceDecorator : IMemberService
{
private readonly Func<IMemberService> decorateeFactory;
private readonly Container container;
public ThreadScopedMemberServiceDecorator(Func<IMemberService> decorateeFactory,
Container container)
{
this.decorateeFactory = decorateeFactory;
this.container = container;
}
public void Save(List<Member> members)
{
using (ThreadScopedLifestyle.BeginScope(container))
{
IMemberService service = this.decorateeFactory.Invoke();
service.Save(members);
}
}
}
You now register this as a (Singleton) Decorator in the Simple Injector Container like this:
container.RegisterDecorator(
typeof(IMemberService),
typeof(ThreadScopedMemberServiceDecorator),
Lifestyle.Singleton);
The container will provide a class which depends on IMemberService with this ThreadScopedMemberServiceDecorator. In this the container will inject a Func<IMemberService> which, when invoked, will return an instance from the container using the configured lifestyle.
Adding this Decorator (and its registration) and changing the lifestyles will fix the issue from your example.
I expect however that your application will in the end have an IMemberService, IUserService, ICustomerService, etc... So you need a decorator for each and every IXXXService, not very DRY if you ask me. If all services will implement Save(List<T> items) you could consider creating an open generic interface:
public interface IService<T>
{
void Save(List<T> items);
}
public class MemberService : IService<Member>
{
// same code as before
}
You register all implementations in one line using Batch-Registration:
container.Register(typeof(IService<>),
new[] { Assembly.GetExecutingAssembly() },
Lifestyle.Scoped);
And you can wrap all these instances into a single open generic implementation of the above mentioned ThreadScopedServiceDecorator.
It would IMO even be better to use the command / handler pattern (you should really read the link!) for this type of work. In very short: In this pattern every use case is translated to a message object (a command) which is handled by a single command handler, which can be decorated by e.g. a SaveChangesCommandHandlerDecorator and a ThreadScopedCommandHandlerDecorator and LoggingDecorator and so on.
Your example would then look like:
public interface ICommandHandler<TCommand>
{
void Handle(TCommand command);
}
public class CreateMemberCommand
{
public string MemberName { get; set; }
}
With the following handlers:
public class CreateMemberCommandHandler : ICommandHandler<CreateMemberCommand>
{
//notice that the need for MemberRepository is zero IMO
private readonly IGenericRepository<Member> memberRepository;
public CreateMemberCommandHandler(IGenericRepository<Member> memberRepository)
{
this.memberRepository = memberRepository;
}
public void Handle(CreateMemberCommand command)
{
var member = new Member { Name = command.MemberName };
this.memberRepository.Insert(member);
}
}
public class SaveChangesCommandHandlerDecorator<TCommand>
: ICommandHandler<TCommand>
{
private ICommandHandler<TCommand> decoratee;
private DbContext db;
public SaveChangesCommandHandlerDecorator(
ICommandHandler<TCommand> decoratee, DbContext db)
{
this.decoratee = decoratee;
this.db = db;
}
public void Handle(TCommand command)
{
this.decoratee.Handle(command);
this.db.SaveChanges();
}
}
And the form can now depend on ICommandHandler<T>:
public partial class frmMember : Form
{
private readonly ICommandHandler<CreateMemberCommand> commandHandler;
public frmMember(ICommandHandler<CreateMemberCommand> commandHandler)
{
InitializeComponent();
this.commandHandler = commandHandler;
}
private void btnSave_Click(object sender, EventArgs e)
{
this.commandHandler.Handle(
new CreateMemberCommand { MemberName = txtName.Text });
}
}
This can all be registered as follows:
container.Register(typeof(IGenericRepository<>),
typeof(GenericRepository<>));
container.Register(typeof(ICommandHandler<>),
new[] { Assembly.GetExecutingAssembly() });
container.RegisterDecorator(typeof(ICommandHandler<>),
typeof(SaveChangesCommandHandlerDecorator<>));
container.RegisterDecorator(typeof(ICommandHandler<>),
typeof(ThreadScopedCommandHandlerDecorator<>),
Lifestyle.Singleton);
This design will remove the need for UnitOfWork and a (specific) service completely.

Auto Dispose Sql Connections properly

My application is using 3 layers: DAL / Service / UL.
My typical DAL class looks like this:
public class OrdersRepository : IOrdersRepository, IDisposable
{
private IDbConnection _db;
public OrdersRepository(IDbConnection db) // constructor
{
_db = db;
}
public void Dispose()
{
_db.Dispose();
}
}
My service calls the DAL class like this (injecting a database connection):
public class ordersService : IDisposable
{
IOrdersRepository _orders;
public ordersService() : this(new OrdersRepository(new Ajx.Dal.DapperConnection().getConnection()))
{
}
public ordersService(OrdersRepository ordersRepo)
{
_orders = ordersRepo;
}
public void Dispose()
{
_orders.Dispose();
}
}
And then finally within my UI layer, this is how I access my service layer:
public class OrdersController : Controller, IDisposable
{
//
// GET: /Orders/
private ordersService _orderService;
public OrdersController():this(new ordersService())
{
}
public OrdersController(ordersService o)
{
_orderService = o;
}
void IDisposable.Dispose()
{
_orderService.Dispose();
}
}
This all works good. But as you can see, I am relying on IDisposable within every layer. UI disposes service object and then service object disposes DAL object and then DAL object disposes the database connection object.
I am sure there has to be a better way of doing it. I am afraid users can forget to dispose my service object (within UI) and I will end up with many open database connections or worse. Please advise the best practice. I need a way to auto-dispose my database connections OR any other unmanaged resources (files etc).

Your question comes back to the principle of ownership:
he who has ownership of the resource, should dispose it.
Although ownership can be transferred, you should usually not do this. In your case the ownership of the IDbConnection is transferred from the ordersService to the OrdersRepository (since OrdersRepository disposes the connection). But in many cases the OrdersRepository can't know whether the connection can be disposed. It can be reused throughout the object graph. So in general, you should not dispose objects that are passed on to you through the constructor.
Another thing is that the consumer of a dependency often can't know if a dependency needs disposal, since whether or not a dependency needs to be disposed is an implementation detail. This information might not be available in the interface.
So instead, refactor your OrdersRepository to the following:
public class OrdersRepository : IOrdersRepository {
private IDbConnection _db;
public OrdersRepository(IDbConnection db) {
_db = db;
}
}
Since OrdersRepository doesn't take ownership, IDbConnection doesn't need to dispose IDbConnection and you don't need to implement IDisposable. This explicitly moves the responsibility of disposing the connection to the OrdersService. However, ordersService by itself doesn't need IDbConnection as a dependency; it just depends on IOrdersRepository. So why not move the responsibility of building up the object graph out of the OrdersService as well:
public class OrdersService : IDisposable {
private readonly IOrdersRepository _orders;
public ordersService(IOrdersRepository ordersRepo) {
_orders = ordersRepo;
}
}
Since ordersService has nothing to dispose itself, there's no need to implement IDisposable. And since it now has just a single constructor that takes the dependencies it requires, the class has become much easier to maintain.
So this moves the responsibility of creating the object graph to the OrdersController. But we should apply the same pattern to the OrdersController as well:
public class OrdersController : Controller {
private ordersService _orderService;
public OrdersController(ordersService o) {
_orderService = o;
}
}
Again, this class has become much easier to grasp and it doesn't needs to dispose anything, since it doesn't has or took ownership of any resource.
Of course we just moved and postponed our problems, since obviously we still need to create our OrdersController. But the difference is that we now moved the responsiblity of building up object graphs to a single place in the application. We call this place the Composition Root.
Dependency Injection frameworks can help you making your Composition Root maintainable, but even without a DI framework, you build your object graph quite easy in MVC by implementing a custom ControllerFactory:
public class CompositionRoot : DefaultControllerFactory {
protected override IController GetControllerInstance(
RequestContext requestContext, Type controllerType) {
if (controllerType == typeof(OrdersController)) {
var connection = new Ajx.Dal.DapperConnection().getConnection();
return new OrdersController(
new OrdersService(
new OrdersRepository(
Disposable(connection))));
}
else if (...) {
// other controller here.
}
else {
return base.GetControllerInstance(requestContext, controllerType);
}
}
public static void CleanUpRequest() }
var items = (List<IDisposable>)HttpContext.Current.Items["resources"];
if (items != null) items.ForEach(item => item.Dispose());
}
private static T Disposable<T>(T instance)
where T : IDisposable {
var items = (List<IDisposable>)HttpContext.Current.Items["resources"];
if (items == null) {
HttpContext.Current.Items["resources"] =
items = new List<IDisposable>();
}
items.Add(instance);
return instance;
}
}
You can hook your custom controller factory in the Global asax of your MVC application like this:
public class MvcApplication : System.Web.HttpApplication
{
protected void Application_Start()
{
ControllerBuilder.Current.SetControllerFactory(
new CompositionRoot());
}
protected void Application_EndRequest(object sender, EventArgs e)
{
CompositionRoot.CleanUpRequest();
}
}
Of course, this all becomes much easier when you use a Dependency Injection framework. For instance, when you use Simple Injector (I'm the lead dev for Simple Injector), you can replace all of this with the following few lines of code:
using SimpleInjector;
using SimpleInjector.Integration.Web;
using SimpleInjector.Integration.Web.Mvc;
public class MvcApplication : System.Web.HttpApplication
{
protected void Application_Start()
{
var container = new Container();
container.RegisterPerWebRequest<IDbConnection>(() =>
new Ajx.Dal.DapperConnection().getConnection());
container.Register<IOrdersRepository, OrdersRepository>();
container.Register<IOrdersService, OrdersService>();
container.RegisterMvcControllers(Assembly.GetExecutingAssembly());
container.Verify();
DependencyResolver.SetResolver(
new SimpleInjectorDependencyResolver(container));
}
}
There are a few interesting things going on in the code above. First of all, the calls to Register tell Simple Injector that they need to return a certain implementation should be created when the given abstraction is requested. Next, Simple Injector allows registering types with the Web Request Lifestyle, which makes sure that the given instance is disposed when the web request ends (just as we did in the Application_EndRequest). By calling RegisterMvcControllers, Simple Injector will batch-register all Controllers for you. By supplying MVC with the SimpleInjectorDependencyResolver we allow MVC to route the creation of controllers to Simple Injector (just as we did with the controller factory).
Although this code might be a bit harder to understand at first, the use of a Dependency Injection container becomes really valuable when your application starts to grow. A DI container will help you keeping your Composition Root maintainable.

Well, if you're really paranoid about that you can use the finalizer (destructor) to automatically execute the Dispose when the object is being garbage collected. Check this link which explains basically all you need to know about IDisposable, skip to the Examples section if just want a quick sample how to do that. The finalizer(destructor) is the ~MyResource() method.
But any way, you should always encourage the consumers of your libraries to use correctly the Dispose. The automatic cleaning up, by means of garbage collector still presents flaws. You don't know when the garbage collector will do its job, so if you get lots of these classes instantiated and used, then forgotten, in a short time, you may still be in trouble.

Autofac Registration technique for this specific issue

I have this class:
public class AutofacEventContainer : IEventContainer
{
private readonly IComponentContext _context;
public AutofacEventContainer(IComponentContext context)
{
_context = context;
}
public IEnumerable<IDomainEventHandler<T>> Handlers<T>(T domainEvent)
where T : IDomainEvent
{
return _context.Resolve<IEnumerable<IDomainEventHandler<T>>>();
}
}
The IEventContainer look like this:
public interface IEventContainer
{
IEnumerable<IDomainEventHandler<T>> Handlers<T>(T domainEvent)
where T : IDomainEvent;
}
Now this IEventContainer is used in a class DomainEvents like this:
public static class DomainEvents
{
....................................
....................................
public static IEventContainer Container;
public static void Raise<T>(T domainEvent) where T : IDomainEvent
{
if (Container != null)
foreach (var handler in Container.Handlers(domainEvent))
handler.Handle(domainEvent);
// registered actions, typically used for unit tests.
if (_actions != null)
foreach (var action in _actions)
if (action is Action<T>)
((Action<T>)action)(domainEvent);
}
}
My aim is to have the DomainEvents.Container registered so that all handlers are resolved.
public class SomeModule : Module
{
protected override void Load(ContainerBuilder builder)
{
base.Load(builder);
//Wrong way in Autofac
//Because the following line is Ninject-like
DomainEvents.Container = new AutofacContainer(componentContext);
//What is the correct way to register it to achieve the above intent?
}
}
What is the way to do this in Autofac?

You are going to have a memory leak if you resolve out of the root scope. (See this post for a good overview of lifetime scopes in Autofac.) A better way to do it would be like this:
interface IEventRaiser
{
void Raise<TEvent>(TEvent #event) where TEvent : IDomainEvent;
}
class AutofacEventRaiser : IEventRaiser
{
private readonly ILifetimeScope context;
public AutofaceEventRaiser(ILifetimeScope context)
{
this.context = context;
}
public void Raise<TEvent>(TEvent #event) where TEvent : IDomainEvent
{
using(var scope = context.BeginLifetimeScope("eventRaiser"))
{
foreach(var handler in scope.Resolve<IEnumerable<IDomainEventHandler<TEvent>>>())
{
handler.Handle(#event);
}
} // scope is disposed - no memory leak
}
}
// then, in the composition root:
IContainer theContainer = BuildTheAutofacContainer();
DomainEvents.EventRaiser = new AutofacEventRaiser(theContainer);
This is the simple answer, but there is one more caveat you should be aware of...
The question is whether you really want to use a static IEventRaiser. DI purists will generally say, "no - you should inject an instance of your IEventRaiser into every class that needs one", but others have argued that a static event raiser is OK.
Be sure you are aware of how Autofac's lifetime scopes work before you make this decsion, because it could affect component sharing. For example, say SomeClass has an instance of SomeDependency and it raises SomeEvent. Let us also assume that SomeDependency is InstancePerLifetimeScope.
If SomeClass gets the IEventRaiser injected, then the handlers will be invoked on the same lifetime scope, and will be injected with the same instance of SomeDependency.
If SomeClass uses a static IEventRaiser, then the handlers will be invoked on a different lifetime scope, and will be injected with a different instance of SomeDependency.
You can see why this matters if you imagine that SomeDependency is something like a DB transaction.

How to implement IDisposable inheritance in a repository?

I am creating a generic repository and do not know what the correct way to implement the dispose functionality:
I'm not using IoC/DI, but i'll refactor my code in the future to do this, so:
My code:
IUnitOfWork Interface:
namespace MyApplication.Data.Interfaces
{
public interface IUnitOfWork
{
void Save();
}
}
DatabaseContext class:
namespace MyApplication.Data.Infra
{
public class DatabaseContext : DbContext, IUnitOfWork
{
public DatabaseContext(): base("SQLDatabaseConnectionString")
{
Database.SetInitializer<DatabaseContext>(null);
}
protected override void OnModelCreating(DbModelBuilder modelBuilder)
{
// Same code.
base.OnModelCreating(modelBuilder);
}
#region Entities mapping
public DbSet<User> User { get; set; }
// >>> A lot of tables
#endregion
public void Save()
{
base.SaveChanges();
}
}
}
IGenericRepository interface:
namespace MyApplication.Data.Interfaces
{
public interface IGenericRepository<T> where T : class
{
IQueryable<T> GetAll();
IQueryable<T> Get(Expression<Func<T, bool>> predicate);
T Find(params object[] keys);
T GetFirstOrDefault(Expression<Func<T, bool>> predicate);
bool Any(Expression<Func<T, bool>> predicate);
void Insert(T entity);
void Edit(T entity);
void Delete(Expression<Func<T, bool>> predicate);
}
}
GenericRepository class:
namespace MyApplication.Data.Repositories
{
public class GenericRepository<T> : IDisposable, IGenericRepository<T> where T : class
{
private DatabaseContext _context;
private DbSet<T> _entity;
public GenericRepository(IUnitOfWork unitOfWork)
{
if (unitOfWork == null)
throw new ArgumentNullException("unitofwork");
_context = unitOfWork as DatabaseContext;
_entity = _context.Set<T>();
}
public IQueryable<T> GetAll()
{
return _entity;
}
public IQueryable<T> Get(Expression<Func<T, bool>> predicate)
{
return _entity.Where(predicate).AsQueryable();
}
// I delete some of the code to reduce the file size.
#region Dispose
public void Dispose()
{
// HERE IS MY FIRST DOUBT: MY METHOD ITS OK?!
// I saw implementations with GC.Suppress... and dispose in destructor, etc.
_context.Dispose();
}
#endregion
}
}
IUserRepository interface:
namespace MyApplication.Data.Interfaces
{
public interface IUserRepository : IGenericRepository<User> { }
}
UserRepository class:
namespace MyApplication.Data.Repositories
{
public class UserRepository : GenericRepository<User>, IUserRepository, IDisposable
{
public UserRepository(IUnitOfWork unitOfWork) : base(unitOfWork) {}
}
}
UserController controller class:
namespace MyApplication.Presentation.MVCWeb.Controllers
{
[Authorize]
public class UserController : Controller
{
private IUserRepository _userRepository;
private IProfileRepository _profileRepository;
private IUnitOfWork _unitOfWork;
public UserController()
{
this._unitOfWork = new DatabaseContext();
this._userRepository = new UserRepository(_unitOfWork);
this._profileRepository = new ProfileRepository(_unitOfWork);
}
public ActionResult List()
{
return View(this._userRepository.GetAll().ToList());
}
public ActionResult Create()
{
ViewBag.Profiles = new SelectList(this._profileRepository.GetAll().ToList(), "Id", "Name");
return View(new User());
}
[HttpPost]
[ValidateAntiForgeryToken]
public ActionResult Create([Bind(Exclude = "Id, Status, CompanyId")] User model)
{
ViewBag.Profiles = new SelectList(this._profileRepository.GetAll().ToList(), "Id", "Name");
if (ModelState.IsValid)
{
model.EmpresaId = 1;
model.Status = Status.Active;
_userRepository.Insert(model);
_unitOfWork.Save();
return RedirectToAction("List");
}
else
{
return View();
}
}
}
So, when and how i disposal my controller and/or my repositories and context?

UPDATED ANSWER:
Example of my controller:
private IGenericRepository<Profile> _repository;
private IUnitOfWork _unitOfWork = new DatabaseContext();
public ProfileController()
{
this._repository = new GenericRepository<Profile>(_unitOfWork);
}
public class ProfileController : Controller
{
private IGenericRepository<Profile> _repository;
private IUnitOfWork _unitOfWork = new DatabaseContext();
public ProfileController()
{
this._repository = new GenericRepository<Profile>(_unitOfWork);
}
}
With the code that you have now, the best thing to do is to override Controller.Dispose(bool disposing) and dispose of the repository in there.
protected override void Dispose(bool disposing)
{
if (disposing)
{
IDisposable d = _repository as IDisposable;
if (d != null)
d.Dispose();
GC.SupressFinalize(this);
}
base.Dispose(disposing);
}
Once you start using an IOC container, all of this disposal code will go away. Construction and disposal should happen at the container level. The container will be the only place where it is known or cared that the repository and unit of work are disposable.
But I suspect that none of these classes need to be disposable in the first place. You should use SqlConnection in a using block. It does not need to be a class-level field in DatabaseContext.
Please forgive the length of this answer. I must establish some fundamentals in order for my recommendation to make sense.
S.O.L.I.D.
SOLID ... stands for five basic principles of object-oriented programming and design. The two principles that are of concern here are the I and S.
Interface Segregation Principle (ISP)
Including IDisposable on the IGenericRepository<T> interface explicitly violates the ISP.
It does this because a repository's disposability (and the imperative to properly dispose of the object) is unrelated to it's designed purpose, which is to Get and Store aggregate root objects. By combining the interfaces together, you get a non-segregated interface.
Why is this important aside from violating some theoretical principle? I will explain that below. But first I have to cover another of the SOLID principles:
Single Resposibility Principle
I always keep this article, Taking the Single Responsibility Principle Seriously, handy when I re-factor functional code into good OO code. This is not an easy subject and the article is very dense. But it is invaluable as a thorough explanation of SRP.
Understanding SRP and disregarding the flaws in 99.9% of all MVC controllers out there which take many DI constructor parameters, the one flaw that is pertinent here is:
Making the controller be responsible for both using the repository and disposing of the repository crosses over to a different level of abstraction, and this violates the SRP.
Explanation:
So you're calling at least two public methods on the repository object. One to Get an object and one to Dispose of the repository. There's nothing wrong with that, right? Ordinarily no, there is nothing wrong with calling two methods on the repository or any object.
But Dispose() is special. The convention of disposal of an object is that it will no longer be useful after being disposed. This convention is one reason why the using pattern establishes a separate code block:
using (var foo = new Bar())
{
... // This is the code block
}
foo.DoSomething(); // <- Outside the block, this does not compile
This is technically legal:
var foo = new Bar();
using (foo)
{
... // This is the code block
}
foo.DoSomething(); // <- Outside the block, this will compile
But this gives a warning of usage of an object after it has been disposed. This is not proper which is why you don't see examples of this usage in the MS documentation.
Because of this unique convention, Dispose(), is more closely related to constructing and destructing an object than to the usage of other members of an object, even though it is exposed as a simple public method.
Construction and Disposal are on the same low level of abstraction. But because the controller is not constructing the repository itself, it lives on a higher level of abstraction. When disposing the repository, it is reaching outside of its level of abstraction to fiddle with the repository object at a different level. This violates the SRP.
Code Reality
Okay, all that theory means exactly what as far as my code is concerned?
Consider what the controller code looks like when it disposes of the repository itself:
public class CustomerController : Controller
{
IGenericRepository<Customer> _customerRepo;
IMapper<Customer, CustomerViewModel> _mapper;
public CustomerController(
IMapper<Customer, CustomerViewModel> customerRepository,
IMapper<Customer, CustomerViewModel> customerMapper)
{
_customerRepo = customerRepository;
_customerMapper = customerMapper;
}
public ActionResult Get(int id)
{
CustomerViewModel vm;
using (_customerRepo) // <- This looks fishy
{
Customer cust = _customerRepo.Get(id);
vm = _customerMapper.MapToViewModel(cust);
}
return View(wm);
}
public ActionResult Update(CustomerViewModel vm)
{
Customer cust = _customerMapper.MapToModel(vm);
CustomerViewModel updatedVm;
using(_customerRepo) // <- Smells like 3 week old flounder, actually
{
Customer updatedCustomer = _customerRepo.Store(cust);
updatedVm = _customerMapper.MapToViewModel(updatedCustomer);
}
return View(updatedVm);
}
}
The controller must receive a useful (non disposed) repository when it is constructed. This is a common expectation. But don't call two methods in the controller or it will break. This controller is a one-shot deal only. Plus, you cannot even call one public method from within another. E.g. the Update method could call Get after storing the model in the repository in order to return an updated Customer View. But this would blow up.
Conclusion
Receiving the repository as a parameter means that something else is responsible for creating the repository. That something else should also be responsible for properly disposing of the repository.
The alternative of disposing an object at the same level of abstraction as using its (other) public members, when the lifetime of the object and possible subsequent usage of the object is not under direct control, is a ticking time bomb.
The rule of IDisposable is this: It is never acceptable to inherit IDisposable in a another functional interface declaration because IDisposable is never a functional concern, but an implementation detail only.

Have your Interface inherit from IDisposable:
public interface IGenericRepository<T> : IDisposable where T : class
{
//...
}
Class:
public class GenericRepository<T> : IGenericRepository<T>
{
public void Dispose()
{
//....
}
}

Single Resposibility Principle
If you look at SRP and use that in MVC it tells you that when you have transactions that are made up of multiple methods (CRUDS) thats not a correct way of implementing the transactions.
So you should put those multiple (CRUD) methods in one method and in that Transaction method implement using for the database context so you can pass that database context to those called private methods that make up the transaction method. If all those (CRUD) methods succeed you can call the Commit method (SaveChanges). When those methods fail you do nothing (=Rollback). So make sure no Commit is executed in those methods but delegate it to the Transaction method.
By implementing the 2nd bullet IDispose is not needed in Repositories because using takes care of cleaning up the database context.
If Connection Pooling is used thats an efficient way of implementing it and it will be scalable.
In the way you setup a Class above it feels wrong. Because in the constructor for the Repository you could set the database context and use that same contextin several methods but then you would need to implement IDispose because you need to cleanup the connections yourself. In lots of examples for Repositories its implemented this way buts from a SRP point of view thats not right and should be changed according to the 2nd bullet above.

Context: You asked for the correct way to implement the dispose functionality.
Solution: This is an alternative for this and any other cases. this automatic alternative is suggested by Visual Studio itself (I tested in VS2017 and VS2019) :
Add the IDisposable contract next to your class name => class MyClass : IDisposable
Then with cursor still on that word "IDisposable", do Alt+Enter or Ctrl+. to enable "Quick Actions"
Then select "Implement interface with Dispose pattern"
Finally you can complete that code-pattern for your managed and unmanaged objects following suggestions indicated in comments.