I would like to ask some help regarding Dependency Injection and, I think, architectural approach.
So, I have an ORM layer implemented by EF6 where the objects are described and Ef does what its business, etc. I created a custom library over it, called DatabaseApi and it is mentioned in the title as "Api", where I query the data and map it to datacontract objects. I do it for pure testing purposes. I would like to have the different libraries in my application testable.
I started to implement the code where I inject the DbContext but I don't know how to deal with the usings in this case.
I went through a few blogposts and articles about mocking and EF, especially this one but it is rather about testing EF itself and not about how to decouple it from other libraries. On the other hand, I assume my search keywords were not proper.
Do you know any good and usable tutorials and articles about how to decouple entity framework from other libraries?
Thanks in advance!
Examples:
I created an empty interface in order to the DbContext can be injectable. It is implemented by the databaseContext.
public interface IDatabase
{
}
public class DatabaseModelContext : DbContext, IDatabase{
public DbSet<TableOne> TableOne { get; set; }
public DbSet<TableTwo> TableTwo { get; set; }
}
In the custom Api library constructor I put together a code to resolve the interface by Unity. I don't know whether it is working or not. I haven't executed yet.
public partial class DatabaseApi : IDatabaseApi {
private readonly IDatabase iDatabase;
private readonly UnityContainer unityContainer;
public DatabaseApi()
{
this.unityContainer = new UnityContainer();
this.unityContainer.RegisterType<IDatabase, DatabaseModelContext>();
this.iDiLibDatabase = this.unityContainer.Resolve<IDiLibDatabase>();
}
}
And here is the problem. Due to the injection I'll have and interface but there are the usings which are important to manage the resource as far as I know. How to do it?
public partial class DatabaseApi : IDatabaseApi
{
public List<SomeDataContract> GetMainStructure()
{
var result = new List<SomeDataContract>();
//this is the old implementation
using (var database = new DatabaseModelContext())
{
//some data manipulation magic... :)
}
return result;
}
If you're okay using linq to objects as a core element of your domain access layer then exposing an IQueryable for access to the entities would work...
public interface IRepository<TEntity>
{
IQueryable<TEntity> AllEntities { get; }
}
With that, you can do your Where, Select, etc. without hard wiring directly to EF. Behind the scenes the IRepository implementations would deal with the EF portions, database connectivity, etc. There's no avoiding coupling the to EF at the data access layer. But you can keep it constrained to just that layer using something like you've started. Just make sure the database contexts used by your IRepository objects are the only objects working with EF.
Put another way: Don't have your IDatabase return entities. Just have it deal with the connections, and you should create another layer for domain object access which takes in an IDatabase. In the example I gave, somehow the IRepository implementations would take in an instance of IDatabase.
So, the solution is using Autofac DI framework. I found interesting questions and answers and two really helpful tutorials. Links below:
How do you reconcile IDisposable and IoC?
Dependency Injection with Autofac
Generic Repository and Unit of Work Pattern, Entity Framework, Unit Testing, Autofac IoC Container and ASP.NET MVC
Autofac homepage
Related
I have a typical application with Controllers, Services, Repositories. So, there are 2 projects:
ASP.NET Core WebAPI with controllers
Core with all business logic
The WebAPI should know only about services from Core. In the Core I have public classes (services) that returns DTOs, but these services depends on DbContext that I want to mark as internal. Of course I can't
Error CS0051 Inconsistent accessibility: parameter type
'DevicesDbContext' is less accessible than method
'DeviceService.DeviceService(DevicesDbContext, IMapper)'
I'm using EF Core and instead of own Repositories I use DbContext. I have entity model that I have to use only in Core project. Could you please advice how can I achieve that?
For example my model is:
internal class Device
{
public int Id {get;set;}
}
DbContext:
internal class DevicesDbContext : DbContext
{
public DbSet<Device> Devices {get;set;}
}
Service:
public class DeviceService : IDeviceService
{
public DeviceService(DevicesDbContext dbContext, IMapper mapper)
{
}
..
}
I got that error in constructor of DeviceService. It is not a duplicate because I know what that error mean and how to fix that. Here I asked about design or architecture of this approach because I need to avoid of using models and dbcontext in WebAPI directly
If you don't want to use Repositories to guard data access (which generally still return Entities, not DTOs, so Entities need to be public) then the real question is:
"Why do you want to avoid using the DbContext & Entities in your Web API?"
Entity Framework is a framework. It's purpose is to facilitate data access to make your code easier to write and easier to understand. Just as you chose to use the .Net framework and leverage things like Linq, Generics, etc. by chossing EF you should seek to leverage everything it offers.
If you absolutely must keep the context and entities out of the API assembly references, or want to centralize business logic involving entities between a Web API and another set of MVC controllers then you're looking at building an anemic API. In this case:
Services.DLL -- References DbContext, entities..
public interface ISomethingService
{
IEnumerable<SomeDto> GetSome(/*params*/);
}
public class SomethingService : ISomethingService
{
public SomethingService(SomeDbContext context)
{ // Init stuff.
}
IEnumerable<SomeDto> ISomethingService.GetSome()
{
// Get some stuff and return DTOs.
}
}
Web API DLL -- Only references DTOs.
public class SomeAPI : ISomethingService
{
private ISomethingService Service { get; set; }
public SomeAPI(ISomethingService service)
{
Service = service;
}
public IEnumerable<SomeDto> GetSome()
{
return Service.GetSome();
}
}
The API is anemic in that it just passes requests through to a common service and forwards the response. The API doesn't need to implement the same interface, it can simply accept a reference to the service and consume it, passing through whatever parameters to get the DTOs that it will pass back.
The downside of this approach is that to modify the service you're flipping between the API and the Services layer vs. just working within the API. I don't favor using approaches like this because APIs and such often need to consider details like filtering, paging, etc. so I want to leverage the excellent LINQ capabilities that EF offers. I also leverage EF's IQueryable support heavily to keep my data access layer simple and compact, letting consuming services decide how to fetch the detail they need. Masking this with an extra service boundary adds complexity and inefficiencies as it either results in complex code, lots of very similar functions, and/or wasted memory/processing to return data that is not needed.
I've inherited a WPF MVVM application which has virtually no unit tests. When I tried to write my own, I quickly realised why: the code hasn't been written in a manner that makes it easy to test, with a lot of concrete implementations.
A particular bugbear is the repository. There's an EF context underneath which I can't/don't want to test but I'm struggling to even get the thing to accept Mocks of the EF objects instead.
I'll hold my hand up and say: I'm not a very good architect. Can you help me untangle this a bit, and prod me toward where interfaces and such need to be added?
Here's a sample ViewModel from the application:
public class MyViewModel : BaseViewModel
{
public MyViewModel(MyEFObject mEfObj)
{
//do stuff
}
// properties, methods etc etc
}
They all inherit from BaseViewModel:
public abstract class BaseViewModel : INotifyPropertyChanged
{
private static MyRepository _rep;
protected static MyRepository rep
{
get
{
if (_rep == null)
_rep = new MyRepository();
return _rep;
}
}
// properties, methods etc etc
}
And so to the repository class:
public class MyRepository
{
private MyEntitiesT db = new MyEntitiesT();
//methods and properties that interact with the DB
}
And finally, at the bottom of the heap, that slightly peculiar entity wrapper:
public class MyEntitiesT : MyEntities
{
public MyEntitiesT()
{
var objectContext = (this as IObjectContextAdapter).ObjectContext;
objectContext.CommandTimeout = 0;
}
}
So, I guess I really need an IMyRepositoryInterface over MyRepository, which would allow me to Mock that. But if I'm instantiating a MyViewModel object, how do I get in my mocked repository, since it's specified in BaseViewModel? Do I need to start fiddling with dependency injection?
Poor testability aside, this is a pretty functional application that I don't want to mess with excessively for fear of breaking it. So if there's a way I can get these things decoupled without making major structural changes, or at least by making them piecemeal (i.e. one ViewModel at a atime) it'd be useful.
You are right. You need IRepository and an implementation containing all the EF code like EfRepository.
I also saw that you are passing and EF Object to a ViewModel...
MyEFObject mEfObj
usually you just want to retrieve POCO's from your Repositories and pass in the Repository to the view model.
So start piece by piece. Take your existing repository and define an interface for it and implement it in the repository. And start to exchange the concrete class definition in the constructor with the interface... and then work from there how deep you need and want to go...
And start adding tests on your way... they will build up soon...
Before you use Dependency injection framework start with something like this...
private readonly IRepository _repository;
public MyViewModel() : this(new EfRepository())
{
}
public MyViewModel(IRepository repository)
{
_repository = repository;
}
This should only be an intermediate step but helps you to refactor to implement a contract based on interfaces. After that look for DI and ViewModelLocator pattern
To go with constructor injection and Interfaces is a good step because they are easy mockable and you can also use mocking frameworks to provide expected behavior from within your unit test.
HTH
I'm working on a system where I'd like to have my layers decoupled as much as possible, you know, some kind of modular application to be able to switch databases and stuff without a serious modification of the rest of the system.
So, I've been watching for x-the time one of the talks of Robert C. Martin about good practices, clean code, decoupling architecture etc, to get some inspiration. What I find kinda weird is his description of the system Fitnesse and the way they've implemented store/load methods for WikiPages. I'm linking the video as well: Robert C. Martin - Clean Architecture and Design
What's he describing (at least from my understanding) is that the entity is aware of the mechanism how to store and load itself from some persistent layer. When he wanted to store WikiPages in-memory, he simply overrode the WikiPage and created a new InMemoryWikiPage. When he wanted to store them in a database, he did the same thing...
So, one of my questions is - what is this approach called? I've been learning the whole time about Repository patterns and stuff, and why should be classes like this persistence-ignorant, but I can't seem to find any materials on this thing he did. Because my application will consist of modules, I think this may help to solve my problems without a need for creating some centralized store for my entities... Every module would simply take care of itself including persistence of its entities.
I think the code would look like is something like this:
public class Person : IEntity
{
public int ID { get;set; }
public string Name { get;set; }
public void Save()
{
..
}
public void Update()
{
}
public void Delete()
{
}
...
}
Seems a bit weird, but... Or maybe I misunderstood what he said in the video?
My second question would be, if you don't agree with this approach, what would be the path you'd take in such modular application?
Please provide an example if possible with some explanation.
I'll answer your second question. I think you will be interested as well in Dependency Injection.
I'm not an expert on DI but I'll try to explain as clear as I'm able to.
First off, from wikipedia:
Dependency injection is a software design pattern that allows removing hard-coded dependencies and making it possible to change them, whether at run-time or compile-time.
The primary purpose of the dependency injection pattern is to allow selection among multiple implementations of a given dependency interface at runtime, or via configuration files, instead of at compile time.
There are many libraries around that help you implement this design pattern: AutoFac, SimpleInjector, Ninject, Spring .NET, and many others.
In theory, this is what your code would look like (AutoFac example)
var containerBuilder = new ContainerBuilder();
//This is your container builder. It will be used to register interfaces
// with concrete implementations
Then, you register concrete implementations for interface types:
containerBuilder.RegisterType<MockDatabase>().As<IDatabase>().InstancePerDependency();
containerBuilder.RegisterType<Person>().As<IPerson>().InstancePerDependency();
In this case, InstancePerDependency means that whenever you try to resolve IPerson, you'll get a new instance. It could be for example SingleInstance, so whenever you tried to resolve IPerson, you would get the same shared instance.
Then you build your container, and use it:
var container = containerBuilder.Build();
IPerson myPerson = container.Resolve<IPerson>(); //This will retrieve the object based on whatever implementation you registered for IPerson
myPerson.Id = 1;
myPerson.Save(); //Save your changes
The model I used in this example:
interface IEntity
{
int Id { get; set; }
string TableName { get; }
//etc
}
interface IPerson: IEntity
{
void Save();
}
interface IDatabase
{
void Save(IEntity entity);
}
class SQLDatabase : IDatabase
{
public void Save(IEntity entity)
{
//Your sql execution (very simplified)
//yada yada INSERT INTO entity.TableName VALUES (entity.Id)
//If you use EntityFramework it will be even easier
}
}
class MockDatabase : IDatabase
{
public void Save(IEntity entity)
{
return;
}
}
class Person : IPerson
{
IDatabase _database;
public Person(IDatabase database)
{
this._database = database;
}
public void Save()
{
_database.Save(this);
}
public int Id
{
get;
set;
}
public string TableName
{
get { return "Person"; }
}
}
Don't worry, AutoFac will automatically resolve any Person Dependencies, such as IDatabase.
This way, in case you wanted to switch your database, you could simply do this:
containerBuilder.RegisterType<SqlDatabase>().As<IDatabase>().InstancePerDependency();
I wrote an over simplified (not suitable for use) code which serves just as a kickstart, google "Dependency Injection" for further information. I hope this helps. Good luck.
The pattern you posted is an Active Record.
The difference between Repository and Active Record Pattern is that in Active Record pattern, data query and persistence, and the domain object are in one class, where as in Repository, the data persistence and query are decoupled from the domain object itself.
Another pattern that you may want to look into is the Query Object which, unlike respository pattern where its number of methods will increase in every possible query (filter, sorting, grouping, etc) the query object can use fluent interface to be expressive [1] or dedicated in which one you may pass parameter [2]
Lastly, you may look at Command Query Responsibility Segregation architecture for ideas. I personally loosely followed it, just picked up ideas that can help me.
Hope this helps.
Update base on comment
One variation of Repository pattern is this
UserRepository
{
IEnumerable<User> GetAllUsers()
IEnumerable<User> GetAllByStatus(Status status)
User GetUserById(int id)
...
}
This one does not scale since the repository get's updated for additional query that way be requested
Another variation is to pass query object as parameter to the data query
UserRepository
{
IEnumerable<User> GetAll(QueryObject)
User GetUserById(int id)
...
}
var query = new UserQueryObject(status: Status.Single)
var singleUsers = userRepo.GetAll(query)
Some in .Net world, Linq expression is passed instead of QueryObject
var singleUsers = userRepo.GetAll(user => user.Status == Status.Single)
Another variation is to do dedicate Repository for retrieval on one entity by its unique identifier and save it, while query object is used to submit data retrieval, just like in CQRS.
Update 2
I suggest you get familiar with the SOLID principles. These principles are very helpful in guiding you creating a loosely coupled, high cohesive architecture.
Los Techies compilation on SOLID pricples contains good introductory articles regarding SOLID priciples.
I am learning repository pattern and was reading Repository Pattern with Entity Framework 4.1 and Code First
and Generic Repository Pattern - Entity Framework, ASP.NET MVC and Unit Testing Triangle
about how they implement the repository pattern with Entity Framework.
Saying
•Hide EF from upper layer
•Make code better testable
Make code better testable I do understand, but why hide EF from upper layer?
Looking at their implementation, it seems just wrap the entity framework with a generic method for query the entity framework. Actually what's the reason for doing this?
I am assuming is for
Loose coupling (that's why hide EF from upper layer?)
Avoid repeat writting same LINQ statement for same query
Am I understand this correctly?
If I write a DataAccessLayer which is a class have methods
QueryFooObject(int id)
{
..//query foo from entity framework
}
AddFooObject(Foo obj)
{
.. //add foo to entity framework
}
......
QueryBarObject(int id)
{
..
}
AddBarObject(Bar obj)
{
...
}
Is that also a Repository Pattern?
Explaination for dummy will be great :)
I don't think you should.
The Entity Framework is already an abstraction layer over your database. The context uses the unit of work pattern and each DBSet is a repository. Adding a Repository pattern on top of this distances you from the features of your ORM.
I talked about this in my blog post:
http://www.nogginbox.co.uk/blog/do-we-need-the-repository-pattern
The main reason adding your own repository implementation is so that you can use dependency injection and make your code more testable.
EF is not very testable out of the box, but it's quite easy to make a mockable version of the EF data context with an interface that can be injected.
I talked about that here:
http://www.nogginbox.co.uk/blog/mocking-entity-framework-data-context
If we don't need the repository pattern to make EF testable then I don't think we need it at all.
This picture makes it easy to understand
One thing is to increase testability and have a loose coupling to underlying persistance technology. But you will also have one repository per aggregate root object (eg. an order can be an aggregate root, which also have order lines (which are not aggregate root), to make domain object persistance more generic.
It's also makes it much easier to manage objects, because when you save an order, it will also save your child items (which can be order lines).
It's also an advantage to keep your queries in a central place; otherwise your queries are scattered around and are harder to maintain.
And the first point you mention: "To hide EF" is a good thing! For instance, saving logic can be hard to implement. There are multiple strategies that apply best in different scenarios. Especially when it comes to saving entities which also have changes in related entities.
Using repositories (in combination with UnitOfWork) can centralize this logic too.
Here are some videos with a nice explanation.
Repository systems are good for testing.
One reason being that you can use Dependency Injection.
Basically you create an interface for your repository, and you reference the interface for it when you are making the object. Then you can later make a fake object (using moq for instance) which implements that interface. Using something like ninject you can then bind the proper type to that interface. Boom you've just taken a dependence out of the equation and replaced it with something testable.
The idea is to be able to easily swap out implementations of objects for testing purposes
Hope that makes sense.
The same reason you don't hard code file paths in your app: loose coupling and encapsulation. Imagine an app with hard coded references to "c:\windows\fonts" and the problems that can cause. You shouldn't hard code references to paths so why should you hard code references to your persistence layer? Hide your paths behind config settings (or special folders or whatever your os supports) and hide your persistence behind a repository. It will be much easier to unit test, deploy to other environments, swap implementations, and reason about your domain objects if the persistence concerns are hidden behind a repository.
When you are designing your repository classes to look alike domain object, to provide same data context to all the repositories and facilitating the implementation of unit of work, repository pattern makes sense. please find below some contrived example.
class StudenRepository
{
dbcontext ctx;
StundentRepository(dbcontext ctx)
{
this.ctx=ctx;
}
public void EnrollCourse(int courseId)
{
this.ctx.Students.Add(new Course(){CourseId=courseId});
}
}
class TeacherRepository
{
dbcontext ctx;
TeacherRepository(dbcontext ctx)
{
this.ctx=ctx;
}
public void EngageCourse(int courseId)
{
this.ctx.Teachers.Add(new Course(){CourseId=courseId});
}
}
public class MyunitOfWork
{
dbcontext ctx;
private StudentRepository _studentRepository;
private TeacherRepository _teacherRepository;
public MyunitOfWork(dbcontext ctx)
{
this.ctx=ctx;
}
public StudentRepository StundetRepository
{
get
{
if(_studentRepository==null)
_stundentRepository=new StundetRepository(this.ctx);
return _stundentRepository;
}
}
public TeacherRepository TeacherRepository
{
get
{
if(_teacherRepository==null)
_teacherRepository=new TeacherRepository (this.ctx);
return _teacherRepository;
}
}
public void Commit()
{
this.ctx.SaveChanges();
}
}
//some controller method
public void Register(int courseId)
{
using(var uw=new MyunitOfWork(new context())
{
uw.StudentRepository.EnrollCourse(courseId);
uw.TeacherRepository.EngageCourse(courseId);
uw.Commit();
}
}
I know it is bad provide links in answer here, however wanted to share the video which explains various advantages of Repository Pattern when using it with Entity framework. Below is the link of youtube.
https://www.youtube.com/watch?v=rtXpYpZdOzM
It also provides details about how to implement Repository pattern properly.
I'm a bit confused about when using the "IRepository pattern", when actually to load the data.
Currently I have something like this:
public class MainViewModel : ViewModelBase
{
// EF4 generated ObjectContext
private ScorBotEntities context = new ScorBotEntities();
// Custom IUserRepository class
private IUserRepository userRepository;
public MainViewModel()
{
this.userRepository = new UserRepository(context.Users);
}
public ObservableCollection<User> Users
{
get
{
return new ObservableCollection<User>(userRepository.GetAll());
}
}
}
ScorBotEntities are autogenerated using EF4 (I had a look at POCOs, to much work for this sized project).
You can find the definition of the UserRepository here: http://code.google.com/p/i4prj4-g2/source/browse/ScorBotRobotics/ScorBotRobotics/Repositories/UserRepository.cs
But basically, what I'm wondering about is, why do it even make sense to use a repository here, instead of just writing it like this:
public class MainViewModel : ViewModelBase
{
private ScorBotEntities context = new ScorBotEntities();
public MainViewModel()
{
}
public ObservableCollection<User> Users
{
get
{
return new ObservableCollection<User>(context.Users);
}
}
}
It makes sense to abstract functionality away such as with the UsernameAndPassword method. But in that case, perhaps using some Query Objects would be more ideal?
I am a bit baffled that your context has made its way down to your ViewModel. I believe your GUI layer should never see the context. Context must be opened/kept/closed by the IRepository. Let the data layer (IRepository) return an array/list of Users.
There are a couple of different points here. First, your view models should have no knowledge of the repository - keep your view models as simple as possible.
Second, the IRepository is your public API - so you should have dependencies to this (depend on abstractions rather than concrete implementation between layers).
There are a couple of different (perfectly acceptable ways) to implement the IRepository. One is to have the repository encapsulate the context directly. Another is to use the "unit of work" pattern and have your unitOfWork encapsulate the context and pass the unitOfWork object to each repository. Either way, since you're using EF4, testability is much easier than it used to be. For example, EF4 introduced IObjectSet so that it is easy to provide test doubles and mocks to test your repository.
I highly recommend checking out this whitepaper on Testability and Entity Framework 4.
Separation of concerns
What if you want to change the storage of 'Users', from say SQL to a flat file?
Then context would not be needed, and you'd have to change every use of it, instead of just your IRepository implementation.
Also, ideally you would have your IRepository injected. So you're MainViewModel doesn't care how it gets it's Users.