Effect in application performance by Repository pattern and Unit of work with entity framework in asp.net mvc - asp.net-mvc

I am working with a database where I have more than 75 tables and I am using the repository and unit of work patterns with Entity Framework in an ASP.NET MVC project. I am little bit confused and some query in my mind about object creation. When UnitOfWork initializes, it creates object for all table's entity which is present in UnitOfWork. So it can be heavy for application load.
Here is the interface of unit of work:
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Threading.Tasks;
using Application.Repository;
using Application.Repository.General;
namespace Application.UnitOfWorks
{
public interface IUnitOfWork : IDisposable
{
IGeneralRegionMasterRepository GeneralRegionMasters { get; }
IGeneralSubRegionMasterRepository GeneralSubRegionMasters { get; }
IGeneralCountryMasterRepository GeneralCountryMasters { get; }
IGeneralStateMasterRepository GeneralStateMasters { get; }
IGeneralCityMasterRepository GeneralCityMasters { get; }
int Complete();
}
}
Implementation:
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Threading.Tasks;
using Application.EntityFramework;
using Application.Repository;
using Application.Repository.General;
namespace Application.UnitOfWorks
{
public class UnitOfWork : IUnitOfWork
{
public readonly InventoryDbContext _context;
public UnitOfWork(InventoryDbContext context)
{
_context = context;
GeneralRegionMasters = new GeneralRegionMasterRepository(_context);
GeneralSubRegionMasters = new GeneralSubRegionMasterRepository(_context);
GeneralCountryMasters = new GeneralCountryMasterRepository(_context);
GeneralStateMasters = new GeneralStateMasterRepository(_context);
GeneralCityMasters = new GeneralCityMasterRepository(_context);
}
public IGeneralRegionMasterRepository GeneralRegionMasters { get; private set; }
public IGeneralSubRegionMasterRepository GeneralSubRegionMasters { get; private set; }
public IGeneralCountryMasterRepository GeneralCountryMasters { get; private set; }
public IGeneralStateMasterRepository GeneralStateMasters { get; private set; }
public IGeneralCityMasterRepository GeneralCityMasters { get; private set; }
public int Complete()
{
return _context.SaveChanges();
}
public void Dispose()
{
_context.Dispose();
}
}
}
I want to know about performance effect of it on application. Thank you in advance for help.

I've run into the same problem that you are describing in the past. The structure of the code just feels really heavy since you are creating new instances of 70 repositories even though you may only need one of them. This is why I've just started to avoid adding my own UoW and Repositories when using EF directly because EF already has Repositories and UoW built in (DbSets = Repos, Save Changes does UoW save at the end of all DbSet changes). If you don't want to code directly against a DbContext, just have your DbContext implement the IUnitOfWork interface directly and go off of that. Also have all your DbSets exposed on that UnitOfWork. Then you could have it also implement IMyDbContext and have that expose the DbSets and have this interface also implement IUnitOfWork (or have DbContext -> IMyDbContext -> IUnitOfWork) or break them up if you don't want repo code having access to Save at the bottom. This just ends up making it easier in the long run. No weird code to maintain, no classes to create. If you switch to not use EF, you can still use those same interfaces behind the scenes and the only thing that would have to change would be the DbSet implementation (maybe you can even get that to be generic - create your on DbSets that implement another interface, too). Personally, I'm going down the CQS path so I don't have to worry about repos or UoW anymore. :)
Edit
Example the best I can here! :)
public interface IUnitOfWork
{
int Complete();
Task<int> CompleteAsync();
}
public interface IInventoryDbContext : IUnitOfWork
{
DbSet<GeneralRegionMaster> GeneralRegionMasters { get; }
DbSet<GeneralSubRegionMaster> GeneralSubRegionMasters { get; }
... etc
}
public class MyDbContext : DbContext, IInventoryDbContext
{
public DbSet<GeneralRegionMaster> GeneralRegionMasters { get; set; }
public DbSet<GeneralSubRegionMaster> GeneralSubRegionMasters { get; set;
}
public int Complete() => this.SaveChanges();
public Task<int> CompleteAsync() => this.SaveChangesAsync();
}
If you did a controller level only:
public class MyController : Controller
{
private readonly IInventoryDbContext _context;
public MyController(IInventoryDbContext context)
{
_context = context;
}
public JsonResult CreateGeneralRegionMaster(GeneralRegionMaster entity)
{
_context.GeneralRegionMaster.Add(entity);
var result = _context.Complete();
return Json(result == 1);
}
}
Again, you could do something different for the DbSets and do this instead:
public interface IRepo<T> where T: class
{
// Expose whatever methods you want here
}
public class MyDbSet<T> : DbSet<T>, IRepo<T> where T: class
{
}
Then this changes:
public interface IInventoryDbContext : IUnitOfWork
{
IRepo<GeneralRegionMaster> GeneralRegionMasters { get; }
IRepo<GeneralSubRegionMaster> GeneralSubRegionMasters { get; }
... etc
}
public class MyDbContext : DbContext, IInventoryDbContext
{
public MyDbSet<GeneralRegionMaster> GeneralRegionMasters { get; set; }
public MyDbSet<GeneralSubRegionMaster> GeneralSubRegionMasters { get; set; }
public IRepo<GeneralRegionMaster> GeneralRegionMastersRepo => GeneralRegionMasters;
public IRepo<GeneralSubRegionMaster> GeneralSubRegionMastersRepo => GeneralSubRegionMasters;
public int Complete() => this.SaveChanges();
public Task<int> CompleteAsync() => this.SaveChangesAsync();
}

Re:
When UnitOfWork initializes, it creates object for all table's entity which is present in UnitOfWork. So it can be heavy for application load.
You don't need to initialize all the repo instances in the UoW constructor.
You can create them when they are required in the corresponding getters (lazy initialization):
private IGeneralRegionMasterRepository _generalRegionMasters;
public IGeneralRegionMasterRepository GeneralRegionMasters {
get {
if (_generalRegionMasters == null) {
_generalRegionMasters = new GeneralRegionMasterRepository(_context);
}
return _generalRegionMasters;
}
}

Related

How to move data across layers (MVC5 + EF6 + DDD)?

We have a MVC 5 application using DDD principles. I need to send data from the Base Controller to the Base Repository, so I can log what user executed an operation for auditing purposes. The application structure is: Presentation (MVC 5) > Application (AppService) > Domain (Service) > Infra (Repository). The idea is to keep each layer independent from the other as much as possible.
In the BaseController I have the logged user from the session, that is accessible to all classes in the presentation layer:
public ProfileApp ProfileApp
{
get { return Session?[Constantes.Session.PROFILE] == null ? CreateProfileApp() : (ProfileApp)Session[Constantes.Session.PROFILE]; }
set { Session[Constantes.Session.PROFILE] = value; }
}
How can I get that information to the repository, in the Add method, declared as below:
public class RepositoryBase<TEntity> : IDisposable, IRepositoryBase<TEntity> where TEntity : BaseIdentity
{
protected VGPartnerDBContext _Db;
protected DbSet<TEntity> _DbSet;
public RepositoryBase(VGPartnerDBContext p_VGPartnerDBContext)
{
_Db = p_VGPartnerDBContext;
_DbSet = _Db.Set<TEntity>();
}
protected virtual T Add<T>(T obj) where T: BaseIdentity
{
return _Db.Set<T>().Add(obj);
}
public virtual TEntity Add(TEntity obj)
{
return Add<TEntity>(obj);
}
I would suggest to do the following, From you controller or Application layer you need to transfer and store data in DB right? In that case you need to create an base DTO
class AuditableDto
{
public string Username { get; set; }
public string ModifedBy { get; set; }
public DateTime ModifiedDate { get; set; }
}
And same for your Auditable entities you need a base class like this.
class AuditableEntity
{
public string Username { get; set; }
public string ModifedBy { get; set; }
public DateTime ModifiedDate { get; set; }
}
And then you can for each request from UI to you action methods in controller make a generic filter to add in your AuditableDtos this metada that you need and in same way you propogate this information to the Entities. In DDD you should follow principle of Persistence Ignorance and Infrastructure ignorance, all layer shoud depend on Domain layer.

How To Use CRUD in ASP.Net MVC with EntityFramework CodeFirst in Pattern IUnitofwork

I Have a PhoneBook Project in MVC and use IUnitOfWork .
but I dont Know that How do this project.
the link of the project :
http://www.mediafire.com/download/jy0b5ins5eisy5t/MvcAppPhoneBook.rar
please complate thie project for me
i'm doing CRUD in this project.
I've used generic repo and UoW in my projects as below. You can take reference of this to complete your project. I usually have 4 layer solution architecture:
Core
Model classes
Data
Generic Repo and UoW
DbContext
Code first migrations
Web
applications solution with dependency injection implementation (e.g.Ninject)
Test
Model classes
public class User
{
public int Id { get; set; }
public string Name { get; set; }
}
public class Course
{
public int Id { get; set; }
public string Name { get; set; }
}
MyDbContext.cs:
public class MyDbContext : DbContext
{
public MyDbContext() : base("name=DefaultConnection”)
{
}
public System.Data.Entity.DbSet<User> Users { get; set; }
public System.Data.Entity.DbSet<Course> Courses { get; set; }
}
Unit of Work:
public class UnitOfWork : IUnitOfWork
{
//private variable for db context
private MyDbContext _context;
//initial db context variable when Unit of Work is constructed
public UnitOfWork()
{
_context = new MyDbContext();
}
//property to get db context
public MyDbContext Context
{
//if not null return current instance of db context else return new
get { return _context ?? (_context = new MyDbContext()); }
}
//save function to save changes using UnitOfWork
public void Save()
{
_context.SaveChanges();
}
}
Generic Repository:
public class RepositoryBase<T> : IRepositoryBase<T> where T : class
{
protected readonly IUnitOfWork _unitOfWork;
private readonly IDbSet<T> _dbSet;
public RepositoryBase(IUnitOfWork unitOfWork)
{
_unitOfWork = unitOfWork;
_dbSet = _unitOfWork.Context.Set<T>();
}
public virtual void Save()
{
_unitOfWork.Save();
}
public virtual void Add(T entity)
{
_dbSet.Add(entity);
_unitOfWork.Save();
}
//Similarly you can have Update(), Delete(), GetAll() implementation here
}
Entity Repository inheriting from generic repo:
public class UserRepository:RepositoryBase<User>,IUserRepository
{
public UserRepository(IUnitOfWork unitOfWork) : base(unitOfWork)
{
}
//Here you can also define functions specific to User
}
controller.cs
public class UserController : Controller
{
private readonly IUserRepository _dbUserRepository;
public UserController(IUserRepository dbUserRepository)
{
_dbUserRepository = dbUserRepository;
}
// GET: /User/
public ActionResult Index()
{
var users = _dbUserRepository.GetAll();
return View(users.ToList());
}
//Other CRUD operations
}

best practice to implement repository pattern and unitOfWork in ASP.NET MVC [closed]

Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
I am working on implementing Repository Pattern and UnitOfWork from last few days, which I have completed to upto good extend, I believe. I am sure there are plenty of ways to implement that but what I am interesting to find best approach for that.
I am taking very simple example coded in ASP.NET MVC 5 using visual studio 2013. my main focus of question is implementation of UnitOfWork. is it advisable to use multiple UnitOfWorks for each business concerns implementing repository functions in private method and giving away public functions for controller to use????
I have function table (SQL Server) in the controller class via generic repository. I have IGenericRepository which has IQueryable one function, I have GenericRepository class where i am implementing this interface. I got FunctionContext which is inherited from baseContext. The reason i have baseContext so all the dbcontexts can use one path to hit database but same time keep number of table limited to business need.
now in my approach;
One BaseContext : DbContext
multiple DbContext, bundling all required table to individual business concern that extend BaseContext
Generic Repository Interface (CRUD)
Generic Repository Implementation class
specific Repository class, extending Generic Reposirtory in case require more function on top of CRUD operations.
Individual UnitOfWork --> taking to required repository/ repositories in private method and provide public method only for using functions
Controller call require UnitOfWork to use public methods.
in following program, all i am getting list of function title and passing to controller to print
Generic Repository Interface
public interface IGenericRepository<TEntity> : IDisposable
{
IQueryable<TEntity> GetAll();
}
Generic Repository
public class GenericRepository<TEntity> : IGenericRepository<TEntity> where TEntity : class
{
protected DbSet<TEntity> _DbSet;
private readonly DbContext _dbContext;
public GenericRepository()
{
}
public GenericRepository(DbContext dbContext)
{
this._dbContext = dbContext;
_DbSet = _dbContext.Set<TEntity>();
}
public IQueryable<TEntity> GetAll()
{
return _DbSet;
}
public void Dispose()
{
}
}
BaseContext
public class BaseContext<TContext> : DbContext where TContext : DbContext
{
static BaseContext()
{
Database.SetInitializer<TContext>(null);
}
protected BaseContext()
: base("name = ApplicationDbConnection")
{ }
}
FunctionContext
public class FunctionsContext : BaseContext<FunctionsContext>
{
public DbSet<App_Functions> Functions { get; set; }
}
Function Mapping class
[Table("Functions")]
public class App_Functions
{
public App_Functions()
{
}
[Key]
public int Function_ID { get; set; }
[StringLength(50)]
[Required]
public string Title { get; set; }
public int Hierarchy_level { get; set; }
}
Function Domain class
public class Functions
{
public Functions()
{
}
public int Function_ID { get; set; }
public string Title { get; set; }
public int Hierarchy_level { get; set; }
}
Function_UnitOfWork
public class Function_UnitOfWork
{
private GenericRepository<App_Functions> _function_Repository = new GenericRepository<App_Functions>(new FunctionsContext());
public Function_UnitOfWork()
{
}
private List<Functions> getAllFunctionsFromRepository()
{
List<Functions> query = new List<Functions>();
query = _function_Repository.GetAll().Select(x => new Functions
{
Function_ID = x.Function_ID,
Title = x.Title,
Hierarchy_level = x.Hierarchy_level
}).ToList();
return query;
}
public List<Functions>GetAllFunctions()
{
return getAllFunctionsFromRepository();
}
}
Controller class
public class HomeController : Controller
{
public ActionResult Index()
{
Function_UnitOfWork UOF = new Function_UnitOfWork();
var a1 = UOF.GetAllFunctions();
foreach(var item in a1)
{
var b1 = item.Title;
}
return View();
}
}
While it is opinion based, just the name of of Unit Of Work pattern suggest limited timespan of the object. So the use of it in controller should be something like
public ActionResult Index()
{
using(var UOF = new Function_UnitOfWork()) {
var a1 = UOF.GetAllFunctions();
foreach(var item in a1)
{
var b1 = item.Title;
}
}
return View();
}
Also one approach we use is (in short)
public class DataObject { }
public class Repo: IRepo<T> where T: DataObject
public class RepoController<T> : Controller where T: DataObject {
protected IRepo<T> Repo;
}
So controllers will be generic and will have field for particular repo
You will use some dependency injection tool, like ninject or mef to bound controllers with repos behind the scene.

ASP.NET MVC service layer input output data

I'm following the repository pattern with service layers in my project.
For each view I'm going to create a viewmodel.
What I'm confused is that, should the service layer directly access domain objects and returns them to the controller, or should I use DTOs. If I should use DTOs, where to put them in the project architecture?
Thank you.
Service layer is responsible for mapping (converting) Dto objects and Domain objects by implementing proper business logic.
Your DTO objects should be used in controllers and services.
DTO's are transfered between Controller and Service, on the other hand Domain objects are transfered between Service and Repository
Controller does not know about Domain and Repository does not know about DTO. Service knows both DTO and Domain and converts them each other with business rules like a car between driver and road, like stackoverflow between you and me, like everything, abstraction...
Following code is an example. Consider each namespace is a package.
namespace Controllers
{
using Services;
using DataTransferObjects;
public class CoffeeController
{
public ICoffeeService CoffeeService { get; set; }
public JsonResult GetCoffee(GetCoffeeInDto inDto)
{
var result = CoffeeService.GetCoffee(inDto);
return JsonResult(result);
}
public JsonResult SaveCoffee(SaveCoffeeInDto inDto)
{
var outDto = CoffeeService.SaveCoffee(inDto);
return JsonResult(outDto);
}
}
}
namespace Services
{
using DataTransferObjects;
public interface ICoffeeService
{
GetCoffeeOutDto GetCoffee(GetCoffeeInDto inDto);
SaveCoffeeOutDto SaveCoffee(SaveCoffeeInDto inDto);
}
}
namespace Services.Impl
{
using Services;
using Repository;
using DataTransferObjects;
using Domain;
public class CoffeeService : ICoffeeService
{
public ICoffeeRepository CoffeeRepository { get; set; }
public GetCoffeeOutDto GetCoffee(GetCoffeeInDto inDto)
{
var entity = CoffeeRepository.Get(inDto.Id);
return new GetCoffeeOutDto {Id = entity.Id, Name = entity.Name};
}
public SaveCoffeeOutDto SaveCoffee(SaveCoffeeInDto inDto)
{
var entity = new CoffeeEntity {Name = inDto.Name};
CoffeeRepository.Save(entity);
return new SaveCoffeeOutDto {Id = entity.Id};
}
}
}
namespace Repository
{
using Domain;
public interface ICoffeeRepository
{
CoffeeEntity Get(int id);
void Save(CoffeeEntity coffeeEntity);
}
}
namespace Repository.Impl
{
using Repository;
using Domain;
public class CoffeeRepository:ICoffeeRepository
{
public CoffeeEntity Get(int id)
{
//get entity from db
throw new System.NotImplementedException();
}
public void Save(CoffeeEntity coffeeEntity)
{
//insert entity into db
throw new System.NotImplementedException();
}
}
}
namespace DataTransferObjects
{
public class SaveCoffeeInDto
{
public string Name { get; set; }
}
public class SaveCoffeeOutDto
{
public int Id { get; set; }
}
public class GetCoffeeInDto
{
public int Id { get; set; }
}
public class GetCoffeeOutDto
{
public int Id { get; set; }
public string Name { get; set; }
}
}
namespace Domain
{
public class CoffeeEntity
{
public int Id { get; set; }
public string Name { get; set; }
}
}

Entity Framework Code First, Unit of Work, Repository and shared DbContext

I'm building a web app using EF Code First and ASP.NET MVC. I have following types:
IProblemRepository
EFProblemRepository
ICategoryRepository
EFCategoryRepository
CleanStreets // db context
IUnitOfWork
// etc.
Code snippets :
public interface IUnitOfWork
{
void Save();
}
public class CleanStreets : DbContext, IUnitOfWork
{
public DbSet<User> Users { get; set; }
public DbSet<Role> Roles { get; set; }
public DbSet<Point> Points { get; set; }
public DbSet<Rating> Ratings { get; set; }
public DbSet<Picture> Pictures { get; set; }
public DbSet<Problem> Problems { get; set; }
public DbSet<Comment> Comments { get; set; }
public DbSet<Category> Categories { get; set; }
protected override void OnModelCreating(DbModelBuilder modelBuilder)
{
modelBuilder.Entity<User>()
.HasMany(u => u.Comments)
.WithRequired(c => c.User)
.HasForeignKey(c => c.UserID)
.WillCascadeOnDelete(false);
base.OnModelCreating(modelBuilder);
}
public void Save()
{
this.SaveChanges();
}
}
public class EFProblemRepository : IProblemRepository
{
private readonly CleanStreets data;
public EFProblemRepository(CleanStreets data)
{
this.data = data;
}
public void Save(Problem problem)
{
if (problem.ProblemID == 0)
{
data.Problems.Add(problem);
}
data.Save();
}
...
}
At first, I didn't have a UnitOfWork. I created a new context in every repository. But after I wanted to save a Problem (Problem includes Category), using the Save method provided above, I received the following error:
An entity object cannot be referenced by multiple instances of IEntityChangeTracker
I found, on stackoverflow, that the problem is with my db context and the solution was to create a shared context with the unit of work pattern. I tried to do that (as you can see above) but I still get the error. Every time when I want to store a Problem the error pops. Did I implement a "shared" db context right?
Based on the error message, you may need to detach an object from one context to save it in another. You could also construct a new object copied from the first (deep copy necessary here) in order to do that. There is also additional thought required to handle any foreign keys that don't have object reference counterparts.

Resources