Develop Reference

Decorator design pattern with generic repository

I have been looking at the decorator design pattern (I am new to the subject of design patterns).
I am already using BaseRepository pattern. But I want to use some cache too.
Below sample is just a dump example.
So I have IGenericRepository interface and the implementation to it.
public interface IGenericRepository<T> where T : class
{
T GetById(int id);
IEnumerable<T> GetAll();
Task<T> GetByIdAsync(int id);
T Add(T entity);
void AddRange(IEnumerable<T> entities);
Task<T> AddAsync(T entity);
Task AddRangeAsync(IEnumerable<T> entities);
void Remove(T entity);
void RemoveRange(IEnumerable<T> entities);
int SaveChanges();
Task<int> SaveChangesAsync();
}
Then I created a custom repository for example IBlogRepository
public interface IBlogRepository : IBaseRepository<Blog>
{
public Task<Blog> GetBlogsByCreatorAsync(int creatorId);
}
With the implemantation of BlogRepository
public class BlogRepository : BaseRepository<Blog>, IBlogRepository
{
public BlogRepository(DbContext db) : base(db)
{
}
public Task<Blog> GetBlogsByCreatorAsync(int creatorId) =>
db.Blogs.Where(b => b.CreatorId == creatorId)
.ToListAsync();
}
I thought this is cool, then I realised I need to improve my "speed". I am starting use IMemoryCache, but in Repository code like below.
public class BlogRepository : BaseRepository<Blog>, IBlogRepository
{
public BlogRepository(DbContext db, IMemoryCache cache) : base(db)
{
}
public Task<Blog> GetBlogsByCreatorAsync(int creatorId)
{
// if in cache else go to db
}
}
Then I met with Decorate pattern and I thought why not, I started to use it, but I am struggling now. I created CachedBlogRepository which is implement IBlogRepository, but when I asked to VS implement all interface method...
public class CachedBlogRepository : IBlogRepository
{
//All BaseRepository methods appeared here...
//But I want cache only the GetBlogsByCreatorAsync method
}
So what is the best practice here? Do I missing something or did I something wrong?

It looks like it is a place where CachedRepository pattern can be used.
I highly recommend you to read this beatuiful article about Building a CachedRepository in ASPNET Core
So after applying CachedRepository pattern would look like this:
public List<Blog> GetBlogsByCreatorAsync(int id)
{
string key = MyModelCacheKey + "-" + id;
return _cache.GetOrCreate(key, entry =>
{
entry.SetOptions(cacheOptions);
return _repository.GetBlogsByCreatorAsync(id);
});
}
You can see source code at gihub

First I don't understand this part:
BlogRepository : BaseRepository, IBlogRepository
shouldn't it be just:
BlogRepository : IBlogRepository?
Now when it comes for the Decorator Pattern I would have done this:
public interface IGenericRepository<T> where T : class
{
T GetById(int id);
IEnumerable<T> GetAll();
Task<T> GetByIdAsync(int id);
T Add(T entity);
void AddRange(IEnumerable<T> entities);
Task<T> AddAsync(T entity);
Task AddRangeAsync(IEnumerable<T> entities);
void Remove(T entity);
void RemoveRange(IEnumerable<T> entities);
int SaveChanges();
Task<int> SaveChangesAsync()
}
(Component)
public class BlogRepository : BaseRepository<Blog>, IBlogRepository
{
public BlogRepository(DbContext db) : base(db)
{
}
public Task<Blog> GetBlogsByCreatorAsync(int creatorId) =>
db.Blogs.Where(b => b.CreatorId == creatorId)
.ToListAsync();
}
(Concrete Component)
abstract class Decorator : IGenericRepository<T>
{
protected IGenerecRepository _repository;
public Decorator( IGenerecRepository repository)
{
this._repository = repository;
}
public override Task<Blog> GetBlogsByCreatorAsync()
{
if (this._repository != null)
{
return this._repository.GetBlogsByCreatorAsync();
}
else
{
return string.Empty;
}
}
}
(Base Decorator)
class CacheDecorator : Decorator
{
public CacheDecorator(IGenericRepository repo) : base(repo)
{
}
public override Task<Blog> GetBlogsByCreatorAsync()
{
//cache behavior
}
}
Uasage:
BlogRepository _basicRepo = new BlogRepository();
CacheDecorator _cacheDecorator = new CacheDecorator(_basicRepo);
_cacheDecorator.GetBlogsByCreatorAsync(creatorId);
Decorator Pattern adds behavior to the main basic behavior. It needs a wrappee (the basic component) to wrap new behavior around it.

Generic UnitOfWork

I am trying to create a Repository & UnitOfWork for Data Access Layer. In my current implementation I have to modify my UnitOfWork everytime I create a new repository. I would like to avoid that and also keep the functionality to extend my repository abstract class.
Following is my generic Repository & UnitOfWork interface & classes
public interface IRepositoryBase<T> where T : class
{
IList<T> FindAll();
T FindByCondition(Expression<Func<T, bool>> expression);
void Create(T entity);
void Update(T entity);
void Delete(T entity);
}
public abstract class RepositoryBase<T> : IRepositoryBase<T> where T : class
{
protected DBContext _dbContext { get; set; }
public RepositoryBase(DBContext dbContext)
{
_dbContext = dbContext;
}
//other methods removed
public void Create(T entity)
{
_dbContext.Set<T>().Add(entity);
}
}
public interface IUnitOfWork
{
IReminderRepository Reminder { get; }
void Save();
}
public class UnitOfWork : IUnitOfWork, IDisposable
{
protected DBContext _dbContext { get; set; }
private IReminderRepository _reminderRepository;
public UnitOfWork(DBContext dbContext)
{
_dbContext = dbContext;
}
public IReminderRepository Reminder
{
get
{
return _reminderRepository = _reminderRepository ?? new ReminderRepository(_dbContext);
}
}
public void Save()
{
_dbContext.SaveChanges();
}
public void Dispose()
{
_dbContext.Dispose();
}
}
Here I can extend my Repository as per my specific needs by implementing the specific Repository as
public interface IReminderRepository : IRepositoryBase<Reminder>
{
IList<Reminder> GetAllReminders();
Reminder GetReminderById(Guid id);
Reminder GetReminderByName(string name);
void CreateReminder(Reminder reminder);
void UpdateReminder(Reminder reminder);
void DeleteReminder(Reminder reminder);
}
public class ReminderRepository : RepositoryBase<Reminder>, IReminderRepository
{
public ReminderRepository(DBContext dbContext)
: base(dbContext)
{
_dbContext = dbContext;
}
//other methods removed
public Reminder GetReminderByName(string name)
{
return FindAll()
.OrderByDescending(r => r.Name)
.FirstOrDefault(r => r.Name == name);
//return FindByCondition(r => r.Name == name);
}
}
This is ok but when ever I will create a new Specific Repository I will have to modify the UnitOfWork class as well by adding a new property for the new Repository.
While searching online I found following but it does not work in my case as my RepositoryBase is an abstract class.
public interface IUnitOfWork
{
void Save();
}
public class UnitOfWork : IUnitOfWork, IDisposable
{
private readonly DBContext _dbContext { get; set; }
private readonly Dictionary<Type, object> _repositories = new Dictionary<Type, object>();
public Dictionary<Type, object> Repositories
{
get { return _repositories; }
set { Repositories = value; }
}
public UnitOfWork(DBContext dbContext)
{
_dbContext = dbContext;
}
public IRepositoryBase<T> Repository<T>() where T : class
{
if (Repositories.Keys.Contains(typeof(T)))
{
return Repositories[typeof(T)] as IRepositoryBase<T>;
}
IRepositoryBase<T> repo = new RepositoryBase<T>(_dbContext);//This does not work
Repositories.Add(typeof(T), repo);
return repo;
}
public void Save()
{
_dbContext.SaveChanges();
}
}

You obviously need to get a reference to a IReminderRepository somewhere in your code to be able to use the remainder specific APIs.
If you don't want to extend your UnitOfWork class to return an IReminderRepository, you may create one yourself in the method that actually uses the specific repository, e.g.:
using (var context = new DBContext())
{
IUnitOfWork uow = new UnitOfWork(context);
ReminderRepository repository = new ReminderRepository(context);
Reminder remainder = repository.GetReminderByName("...");
remainder.SomeProperty = "updated value..";
uow.Save();
}
The only purpose of using the unit of work is to be able to share the same context between several different repositories anyway. Exposing a Dictionary<Type, object> in your UnitOfWork won't solve anything as the purpose of using generics is to provide compile-time type safety.

Confusion over using of UnitOfWork in Repository Pattern

It's a week I have been dealing with Repository pattern, somehow I have implemented something, a generic repository:
private CentralEntities db = null;
private DbSet<T> table = null;
public RepositoryTest()
{
this.db = new CentralEntities();
table = db.Set<T>();
}
public RepositoryTest(CentralEntities db)
{
this.db = db;
table = db.Set<T>();
}
public IEnumerable<T> SelectAll()
{
return table.Take(10).ToList();
}
Here is my IRepository:
public interface IRepositoryTest<T> where T:class
{
IEnumerable<T> SelectAll();
}
Here in my Controller I implemented like the following and it works:
public class DashbrdController : Controller
{
IRepositoryTest<Event> _repository = null;
public DashbrdController(IRepositoryTest<Event> _repository)
{
this._repository = _repository;
}
public DashbrdController()
{
this._repository = new RepositoryTest<Event>();
}
public ActionResult DashBrd()
{
var rslt= _repository.SelectAll().Take(10);
return View(rslt);
}
}
First I do not how to implement Iunitofwork and UnitOfWork, and second apart from creating a single gate for update or insert, whats the usage of UnitOfWork? what kind of problem can it solve in the above example?

Please refer to the section below for detail understanding of UOW and Repository:
1) You create Generic Repository (The base of all the data source):
public class GenericRepository : IGenericRepository where T :
class
{
protected DbContext _entities;
protected readonly IDbSet<T> _dbset;
public GenericRepository(DbContext context)
{
_entities = context;
_dbset = context.Set<T>();
}
public IEnumerable<T> GetAll()
{
return _dbset.AsEnumerable();
}
public IEnumerable<T> FindBy(System.Linq.Expressions.Expression<Func<T, bool>> predicate)
{
IEnumerable<T> query = _dbset.Where(predicate).AsEnumerable();
return query;
}
public virtual T GetSingle(System.Linq.Expressions.Expression<Func<T, bool>> predicate)
{
T query = _dbset.Where(predicate).FirstOrDefault();
return query;
}
public virtual void Add(T entity)
{
_dbset.Add(entity);
}
public virtual void Delete(T entity)
{
_dbset.Remove(entity);
}
public virtual void Edit(T entity)
{
_entities.Entry(entity).State = EntityState.Modified;
}
public virtual void Attach(T entity)
{
_dbset.Attach(entity);
}
public virtual void Save()
{
_entities.SaveChanges();
}
}
2) Then you create a Unit Of Work (Generic that adds the instance of Repository)
public sealed class GenericUnitOfWork : IGenericUnitOfWork, IDisposable
{
private ApplicationDbContext entities = null;
private ApplicationUserManager _userManager;
public GenericUnitOfWork()
{
entities = new ApplicationDbContext();
}
public Dictionary<Type, object> repositories = new Dictionary<Type, object>();
public IGenericRepository<T> Repository<T>() where T : class
{
if (repositories.Keys.Contains(typeof(T)) == true)
{
return repositories[typeof(T)] as IGenericRepository<T>;
}
IGenericRepository<T> repo = new GenericRepository<T>(entities);
repositories.Add(typeof(T), repo);
return repo;
}
public int Commit()
{
return entities.SaveChanges();
}
private bool disposed = false;
private void Dispose(bool disposing)
{
if (!this.disposed)
{
if (disposing)
{
entities.Dispose();
}
}
this.disposed = true;
}
public void Dispose()
{
Dispose(true);
GC.SuppressFinalize(this);
}
}
3) Then you call UnitOfWork from your controller, that creates instance of Repository in Generic Form
public class DashbrdController : Controller
{
private GenericUnitOfWork uow = null;
public DashbrdController()
{
uow = new GenericUnitOfWork();
}
public ActionResult DashBrd()
{
var rslt = uow.Repository<Event>().GetAll().ToList();
return View(rslt);
}
}
The unit of work class coordinates the work of multiple repositories by creating a single database context class shared by all of them.
For a specific user action (say adding a event), all the transactions like insert/update/delete and so on are done in one single transaction, rather then doing multiple database transactions. This means, one unit of work here involves insert/update/delete operations, all in one single transaction.
Please make the interfaces with the implementation classes provided above. Let me know if problem occurs in that.
Hope if helps.

Setting the connection string of a DBContext in my repository class using Ninject

I have an MVC 5 application that uses EF 6 and implements Repository pattern with dependency injection using the DI container Ninject. The connection string for the dbcontext is stored in the Web.config file which the EF Context properly finds. Everything works fine. Lately, I have a requirement that the connection to my DBContext need to be determined at runtime and connect to different databases (but with exactly the same structure). So, I need to change the sql connectionstring part from the entity connectionstring at run-time before the repository is instantiated. I would really appreciate some help in doing it. I am not a DI guru; know just enough Ninject to get my things going.
Here is my Repository Base Interface:
public interface IRepositoryBase<T> where T : class
{
void Add(T entity, string userGuid = "");
void Delete(T entity);
// ... removed other method signatures for brevity
}
My Repository base implementation:
public abstract class RepositoryBase<D, T> : IRepositoryBase<T>, IDisposable
where T : class
where D : DbContext, new()
{
private Guid? currUserGuid = null;
private D dataContext;
protected D DataContext
{
get
{
if (dataContext == null)
dataContext = new D();
return dataContext;
}
set { dataContext = value; }
}
public IQueryable<T> FindBy(Expression<Func<T, bool>> predicate)
{
return DataContext.Set<T>().Where(predicate);
}
public virtual IQueryable<T> GetAll()
{
IQueryable<T> query = DataContext.Set<T>();
return query;
}
public virtual void Delete(T entity)
{
OperationStatus stat = TryDelete(entity);
}
// .... removed rest for brevity
}
Interface and implementation for concrete class:
public interface ICustomerRepository : IRepositoryBase<Customer>
{
Customer GetCustomerAndStatus( Guid custGuid );
}
public class CustomerRepository : RepositoryBase<PCDataEFContext, Customer>, ICustomerRepository
{
public Customer GetCustomerAndStatus( Guid custGuid )
{
return DataContext.Customers.Include( x => x.CustStatusType )
.SingleOrDefault( x => x.PKGuid == custGuid );
}
}
My Ninject dependency resolver:
public class NinjectDependencyResolver : IDependencyResolver
{
private IKernel kernel;
public NinjectDependencyResolver()
{
kernel = new StandardKernel();
AddBindings();
}
public IKernel Kernel { get { return kernel; } }
private void AddBindings()
{
kernel.Bind<ICustomerRepository>().To<CustomerRepository>();
// ... other bindings are omitted for brevity
}
}
and finally, here is my Entity Framework generated DBContext:
public partial class PCDataEFContext : DbContext
{
public PCDataEFContext()
: base("name=PCDataEFContext")
{
}
protected override void OnModelCreating(DbModelBuilder modelBuilder)
{
throw new UnintentionalCodeFirstException();
}
public virtual DbSet<Customer> Customers { get; set; }
}
All the above code works great! But as I said in the beginning, I don't know how to inject the connection string into my Repositorybase class at runtime so that I don't have to modify any of my inherited repositories (I have plenty of them). Someone please help.
Babu.

Could you do it like this?
public partial class PCDataEFContext : DbContext
{
public PCDataEFContext()
: base(Util.GetTheConnectionString())
{ }
}
public class MyDerivedContext : PCDataEFContext
{
public MyDerivedContext()
: base()
{ }
}
class Util
{
public static string GetTheConnectionString()
{
// return the correct name based on some logic...
return "name=PCDataEFContext";
}
}
Another way of doing it, could be in the RepositorBase class you defined, by altering the connectionstring after the creation of the dbcontext:
protected D DataContext
{
get
{
if (dataContext == null)
{
dataContext = new D();
dataContext.Database.Connection.ConnectionString = "the new connectionstring";
}
return dataContext;
}
set { dataContext = value; }
}

How and when to dispose my objects?

In my backend service I use unit of work pattern. I was wondering if I'm missing something related to disposing objects.
First, this is the code I have so far, which works. The service just calls a request handler:
[GlobalExceptionHandlerBehaviour(typeof(GlobalExceptionHandler))]
public class CustomerService : ICustomerService
{
public void AddCustomer(AddCustomerRequest request)
{
ObjectFactory.GetInstance<AddCustomerRequestHandler>().Execute(request);
}
}
The request handler looks like:
public class AddCustomerRequestHandler
{
private readonly IUnitOfWork _unitOfWork;
private readonly ICustomerRepository _customerRepository;
public AddCustomerRequestHandler(IUnitOfWork unitOfWork, ICustomerRepository customerRepository)
{
_unitOfWork = unitOfWork;
_customerRepository = customerRepository;
}
public void Execute(AddCustomerRequest request)
{
var customer = new Customer(request.Id, request.CompanyName);
_customerRepository.Add(customer);
_unitOfWork.Commit();
}
}
The unit of work is defined as follows:
public interface IUnitOfWork
{
void Commit();
}
public class UnitOfWork : IUnitOfWork
{
private readonly IDatabaseFactory<EfTrackerDbContext> _databaseFactory;
private EfTrackerDbContext _dataContext;
public UnitOfWork(IDatabaseFactory<EfTrackerDbContext> databaseFactory)
{
_databaseFactory = databaseFactory;
}
public EfTrackerDbContext DataContext
{
get { return _dataContext ?? (_dataContext = _databaseFactory.Get()); }
}
public void Commit()
{
DataContext.Commit();
}
}
The EfTrackerDbContext is the actual EF context:
public class EfTrackerDbContext : DbContext, IUnitOfWork
{
public DbSet<Customer> Customers { get; set; }
public virtual void Commit()
{
base.SaveChanges();
}
protected override void OnModelCreating(DbModelBuilder modelBuilder)
{
base.OnModelCreating(modelBuilder);
modelBuilder.Entity<Customer>().ToTable("Customer");
}
}
And the DatabaseFactory is like:
public class DatabaseFactory<TContext> : DisposableObject, IDatabaseFactory<TContext> where TContext : DbContext, new()
{
private TContext _dataContext;
public TContext Get()
{
return _dataContext ?? (_dataContext = new TContext());
}
protected override void DisposeManagedResources()
{
if (_dataContext != null)
{
_dataContext.Dispose();
_dataContext = null;
}
}
}
The CustomerRepository:
public interface ICustomerRepository : IRepository<Customer>
{
IQueryable<Customer> Customers { get; }
}
public class CustomerRepository : RepositoryBase<EfTrackerDbContext, Customer>, ICustomerRepository
{
public CustomerRepository(IDatabaseFactory<EfTrackerDbContext> databaseFactory)
: base(databaseFactory)
{
}
public IQueryable<Customer> Customers
{
get { return DataContext.Customers; }
}
}
As you see, everything is injected. Registration looks like:
For<IDatabaseFactory<EfTrackerDbContext>>().HybridHttpOrThreadLocalScoped().Use<DatabaseFactory<EfTrackerDbContext>>();
For<IUnitOfWork>().HybridHttpOrThreadLocalScoped().Use<UnitOfWork>();
For<ICustomerRepository>().HybridHttpOrThreadLocalScoped().Use<CustomerRepository>();
Now, the question is about disposing the objects. The only place where IDisposable is implemented is DatabaseFactory, where _datacontext is disposed. I guess that is not enough, so I have following questions:
AddCustomerRequestHandler is injected, so it gets disposed if AddCustomer() service operation ends and garbage collection starts. Is this ok, or should I explicitely call Dispose on the AddCustomerRequestHandler at the end of the AddCustomer() operation and so have it implement IDisposable?
Should UnitOfWork also implement IDisposable, and do I have to call it explicitely?
How to dispose the EfTrackerDbContext ?
Other remarks?
In short, I'm looking for the right way to have everything disposed as soon as the service operation ends.
Thanks for the advice,
L

Whenever you use something that implements IDisposable you should Dispose it as soon as you don't need it any more.
If you use it as a field in a class, implement IDisposable in that class and iterate this process.
PS:
If you turn on Code Analysis like this:
you will get some warnings pointing you to this for free :D