unit-of-work | 易学教程

'unitOfWork parameter cannot be null' in Background Worker

阅读更多关于 'unitOfWork parameter cannot be null' in Background Worker

问题 I've started getting these errors. It was working perfectly on my previous server. using System; using Abp.Dependency; using Abp.Domain.Repositories; using Abp.Threading.BackgroundWorkers; using EMS.IPs; using System.Threading.Tasks.Dataflow; using System.Threading.Tasks; using System.Linq; using EMS.Contacts; using System.Collections.Concurrent; using Abp.Domain.Uow; using System.Collections.Generic; using EMS.EmailValidation; using Microsoft.AspNetCore.SignalR; using KellermanSoftware

Entity Framework 4.1 Database First Dependency Injection Unit of Work

阅读更多关于 Entity Framework 4.1 Database First Dependency Injection Unit of Work

问题 Ok, there are tons of examples using unit of work with dependency injection for Code First, using generic repositories and all that good stuff. Does anyone have an example doing this with Database First (edmx with dbContext Generator (T4)), Stored Procedures as Function Imports, Unit of Work with dependency injection. 回答1: The context for code first or dbfirst will be the same (DbContext). Stored procedures are mapped in your repository instead of calling context.Customers you call context

How to manage client context object in seperate class library?

阅读更多关于 How to manage client context object in seperate class library?

问题 I am trying to create a library(class library) for sharepoint which will have all sharepoint dll to interact with sharepoint server to upload files,documents and create document library and document set . Now this library could be consumed by clients like web application(asp.net webform or mvc) or console application or web api/wcf services or windows form anything. So here I am bit confused with creating repository patterna and unit of work layer in order to manage client context object. I

How to correctly dispose objects registered with Autofac

阅读更多关于 How to correctly dispose objects registered with Autofac

问题 I've implemented Unit of Work/Repository pattern, as described here, but I'm also using autofac and constructor injection, so I registered UnitOfWork and DbContext (PsyProfContext) class like this: builder.Register(context => new PsyProfContext()).InstancePerHttpRequest(); builder.RegisterType<UnitOfWork>().As<IUnitOfWork>().InstancePerHttpRequest(); And everything works great! Except for one thing: I'm also using enterprise library logging block, and I have implemented CustomTraceListener

Generic Class for CRUD - Dependency Injection in C# using Repository and Unit Of Work Pattern

阅读更多关于 Generic Class for CRUD - Dependency Injection in C# using Repository and Unit Of Work Pattern

问题 Trying to create a Generic Repository Class for implementing basic CRUD operations in C# using dependency injection, unit of work and repository patterns. I am very new to these concepts. Following is my code. public interface IUnitOfWork { IApplicationUserRepository Users { get; } ICompanyRepository Companies { get; } void Complete(); } public class UnitOfWork : IUnitOfWork { private readonly ApplicationDbContext _context; public IApplicationUserRepository Users { get; private set; } public

Repository pattern with EF6 + DatabaseFirst

阅读更多关于 Repository pattern with EF6 + DatabaseFirst

问题 Current System: I am working on a project which is multi layered as shown below (in order of flow) and I am learning and trying to implement Repo Pattern with UOW on EF Database first. Service (Web API) Business (C# Class Library) Repository (Repo Pattern + UOW) ViewModels (Used by my Service for sent to my UI layer) Data (Entities) Database (SQL Server) Repository: Generic Repository: public interface IRepository<TEntity> where TEntity : class { void Create(TEntity entity); IQueryable

UnitOfWork and Entity Framework Contexts

阅读更多关于 UnitOfWork and Entity Framework Contexts

问题 So the problem I am trying to solve is this; We are using Entity Framework to access our Oracle database that has 1200-1500 tables. Now mind you we are not accessing them all, but possibly could have 800+ to access. We are using the UnitOfWork --> Repository --> Service pattern and that works great, but we are trying to figure out if we should have one big DbContext, or multiple little contexts that are specific to the task at hand. Our UnitOfWork is setup using an EFUnitOfWorkBase like so:

How to use joins with generic repository pattern - Entity Framework

阅读更多关于 How to use joins with generic repository pattern - Entity Framework

问题 I have a Generic Repository like below which handles my CRUD , for a single entity its easy to use, problem starts when i try to join my POCOs . Lets say I have these POCO, they are mapped using fluent api (many to many and One to many relation) : public class Student { public Student() { this.Courses = new HashSet<Course>(); } public int StudentId { get; set; } public string StudentName { get; set; } //FKs public virtual Standard Standard { get; set; } public int StdandardRefId { get; set; }

Should a Repository implement UnitOfWork?

阅读更多关于 Should a Repository implement UnitOfWork?

问题 In a DDD pattern should the unit of work be coupled with the repository? I've seen several different examples, including a repository that implements a unit of work interface, a repository that implements the behavior for unit of work itself, and a repository that has a property representing the unit of work so that it can be shared across multiple repository instances in the lifetime of the UoW. In the case of the latter, it kind of seems like an anti-pattern...that is, should a consumer

UnitOfWork and Entity Framework Contexts

阅读更多关于 UnitOfWork and Entity Framework Contexts

So the problem I am trying to solve is this; We are using Entity Framework to access our Oracle database that has 1200-1500 tables. Now mind you we are not accessing them all, but possibly could have 800+ to access. We are using the UnitOfWork --> Repository --> Service pattern and that works great, but we are trying to figure out if we should have one big DbContext, or multiple little contexts that are specific to the task at hand. Our UnitOfWork is setup using an EFUnitOfWorkBase like so: public abstract class EFUnitOfWorkBase : IUnitOfWork { private bool isDisposed = false; public