Question on autofac IOC.
My application has MANY concrete classes implementing the same interface. How do I register these in startup, and then resolve them in my controllers?
For example, i just have one IRepository interface for CRUD operations to database, but numerous concrete classes that implement IRepository.
Related
I'm working on an ASP.net Web API application with Autofac and Entity Framework.
I've been breaking apart different my service classes into smaller classes in order to make my code more testable and to make my code more SOLID.
I'm using Autofac to inject Entity Framework DbContext into my various helper classes. This becomes problematic because if I use entities queried from DbContext in two different helper classes, I get an error when Entity Framework tries to produce a query.
The error says that Entity Framework cannot produce a query with entities from two different instances of DbContext.
Clearly, the solution is that I need to configure Autofac so that the same instance of DbContext is injected into each of the helper classes, but I'm afraid that if I try to do this, I may get concurrency issues when this application gets deployed to a production environment and many people use it at once.
How do I configure Autofac so that when a request hits my application, my API helper classes all get the same instance of DbContext, but I don't have concurrency issues across multiple requests?
An alternative to the action filter recommended by the Autofac documentation (https://autofaccn.readthedocs.io/en/latest/faq/per-request-scope.html#no-per-request-filter-dependencies-in-web-api) see: "No Per-Request Filter Dependencies in Web API" and manually going to the DependencyResolver for others:
You could have a look at the Medhime DbContextScope unit of work provider. (https://www.nuget.org/packages/EntityFramework.DbContextScope/) compiled for both EF6 and EF Core.
The injected dependencies for your classes becomes a DbContextScopeFactory for the top level, and an AmbientDbContextLocator for your services. These don't "break" with Web API's limitation on the request lifetime scope. The ContextScopeFactory would be initialized once and supply the DbContext, while the locators will be fed that single instance.
It may be worth having a look at if managing context references across services and an API action prove clunky.
I am trying to Create Class Diagram for my Web Application but i dont know how to Represent Database Connection and REST API in Class diagrams.
P.S. I am Creating Class Diagram by following model view controller pattern.
A class is a class
In your class diagrams, you model classes of your system. And all the classes look alike:
a database connection would be a class like another, that will keep some properties about the database context and offer methods for connecting to and disconnecting from a given database.
a REST API class would be a class (or a set of classes) like any other. If you're the API consumer you would certainly have no properties in these classes (because REST is stateless and properties create a state). You could for example have a method for every service you could invoke.
Conceptually speaking theses classes in your system are proxies for something which is out of your system, and which would invoke the APIs provided by the database and the webservice.
But perhaps you want to model something else ?
If your system offers an API, and you want to show how the API offered to the external world relates to your internal classes, you could be interested in using a composite structure diagram.
If you want to show the different components if your system, especially how these are wired together using an API, you could be interested in the component diagram.
If your question is not so much about the structure of the classes and the deeper internals of your system, but more about showing that some part are on remote servers or in containers, you could even think of deployment diagrams. But these are more about the concrete layout of the operating infrastructure, and to link it to the classes, you'd need the component diagrams first.
I am using Entity Framework and would like to use TPH with interfaces. So I have a created an interface, "ICustomer", which maps to "SimpleCustomer" and "DiscountedCustomer" class as shown below. Below is the model builder code. From what I understand we can not use interfaces with Entity Framework, so what's the best way?
modelBuilder.Entity<ICustomer>().ToTable("tblCustomer")
.Map<SimpleCustomer>(x => x.Requires("CustomerType").HasValue("S"))
.Map<DiscountedCustomer>(x => x.Requires("CustomerType").HasValue("D"));
My application uses interfaces all over the UI and would like to have a smooth type casting to Entity Framework. So is what the best way?
Entity Framework does not support TPH with interfaces (sorry for stating the obvious). This may not be the solution you are looking for, but I am still going to put it there because it seems to be the only solution as of 16 April 2015.
In Entity Framework 6, the closest you can get is - Use abstract classes instead of interfaces. This article talks about TPH in EF in great detail.
My suggestion is if you want to use interfaces and maintain the hierarchy and also still want smooth typecasting, consider using automapper with abstract classes. This way your UI will still use Interfaces, but can be mapped to domain model using automapper profiles. Atleast till the interface support arrives. It will not be a quick one if the application is large and has hundreds of domain models, so need to plan it wisely.
If you are creating it from scratch, you can simply use abstract classes from UI layer to DAL without any re-factoring.
I am trying to implement a caching pattern which may need to utilise Redis. The problem with this pattern is that I need to disable Configuration.ProxyCreationEnabled and then re-enable it afterwards to avoid any issues across a web farm.
What I would like to do is access the DbContext from the IQueryable so I can do this once instead of everywhere. The easiest way to do this is to pass the DbContext being used into my caching extension, however I came across this post:
Access DataContext behind IQueryable
Is there a way of accessing the DbContext in a similar manner to the link above using EF 4.1 Code Fist (DbSet's, etc)?
I have tried to find this myself but have struggled to find the base class from the referenced DbSet in the IQueryable using reflection.
The solution mentioned in Access DataContext behind IQueryable is a hack and should not be used. It relies on the name of a private member variable in the class implementing IQueryable. This means that the implementing class could change in a future release of EF/.NET Framework and break your code. Since the DbContext is not accessible through the IQueryable interface, you should pass it into your caching extension to avoid making assumptions about the IQueryable implementation. Doing so will also more clearly establish the dependency on the DbContext in your caching interface, instead of burying it in the implementation.
I was having a look at CTP5 of EntityFramework and the code first fluent interface. It looks very nice, but is there a way to make the DbContext expose only interface types and the in the fluent interface's model binder define a concrete implementation to use?
No, as of CTP5, EF Code First does not support interfaces and this feature is unlikely to be supported in the RTM that is targeted to be released this year.