Develop Reference

asp.net mvc 5 - creating instance of same class in every method in a class

Im have a question.
I have just started a job with a new company that has one "Senior developer".
In a class he is doing this (Example):
class CarController{
public Cars GetCars(){
**Connection connect = new Connection(); // Create DB connection**
//and here some fetching of the data and returning it with a HTTP Response
}
public Cars GetCar(int id){
**Connection connect = new Connection(); // Create DB connection**
//and here some fetching the car with id, returning it with a HTTP Response
}
//and this pattern continues here...
}
I cant imagine that this is a good practise to keep creating the same instance of a class in each and every method to make call to the Database??
Isn't it also bad for the memory to keep creating instances everywhere?
In my opinion here we could use the repository pattern and only give access to the database class to the class the implements the Interface.
Right now we expose the Database class to the controller and the code is tight coupled!
He says that he cannot understand the concept of the respository an why Interfaces should be used in this case.
How do you convince a senior to refactor the code and also prove to him that his coding has no good structure?
How can i explain the cons in his code above in another way?

I cant imagine that this is a good practice to keep creating the same instance of a class in each and every method to make call to the Database? Isn't it also bad for the memory to keep creating instances everywhere?
It actually IS the best practice in this case. .NET pools database connections, so creating them generally isn't an expensive process. Reusing connections, however, can cause problems.
However, you should be disposing the connection as soon as you're done with it. A handy way of doing that is with a using statement:
using(Connection connect = new Connection()) // Create DB connection
{
//and here some fetching of the data and returning it with a HTTP Response
} // the connection is closed and disposed of here.
In my opinion here we could use the repository pattern and only give access to the database class to the class the implements the Interface. Right now we expose the Database class to the controller and the code is tight coupled!
Sure, that might be an improvement, but it's orthogonal to your first question. The repository should create the connection when needed and dispose of it when done.
How do you convince a senior to refactor the code and also prove to him that his coding has no good structure?
If you've just started, you might not be able to if you approach it that way. Just remember that most people (regardless of experience) don't like others to criticize their work. Instead, offer an alternative solution and offer some reasons why it's an improvement over the current design. A pragmatic approach would be to provide a situation in which the pattern in place causes problems (unit testing is the most obvious) and illustrate why a different design would solve that problem.

Instantiating objects directly isn't always bad
Creating object instances without using an IoC container is not always bad (imagine if we used Container.Resolve every time we wanted to create a string!) If a dependency is not a volatile dependency then it may not be a great candidate for DI.
No it is not expensive
Creating and disposing database connections over and over is not expensive (they are allocated from a pool and kept open anyway) and in fact is considered best practice.
Inject a DB connection?
In the case of a database connection, that connection must be tightly handled and disposed in a quick timeframe, so there is an argument to be made not to inject it. You certainly would not want the caller (or the composition root) to instantiate the connection and then require the consumer of the connection to Dispose it; that is a violation of of two commonly-held principles:
Scope that creates an instance should also destroy it
Injected instances should have longer lifespan than the object using the injected instance
Inject a factory?
Perhaps you could inject a database connection factory, but this is a little problematic because IDBConnection doesn't contain all the members found in SqlConnection. So if you want to use DI here you'd either need to supply a concrete instance (which is sealed, by the way, so no shims) or you'd need to strip away all the SQL-only features from your implementation. Same is true of SqlCommand -- IDBCommand only has a very small subset of the properties, and none of the async methods at all.
What would it gain you?
Would it get you loose coupling? Not really. You'd have sort of a fake loose coupling, but there is an implicit logical coupling between the data access classes and the SQL server database (for example, they have a schema in common). It's not like you could replace your SqlClient with an OracleClient and expect it to work. I've seen lots of folks try it, for years; if you are still trying you haven't caught on. It doesn't work. A feature-rich database client is going to have some hard dependencies on the database platform, period.
Would it be easier to unit test? Not sure. As I noted above, you can't really write shims or stubs because the SqlConnection, SqlCommand, SqlParameter, etc. are all sealed, and all have concrete methods not found in the interfaces. so no matter what, you are still going to be stuck mocking instead of stubbing.
What is the long term plan?
Maybe the plan is to replace all that low level SQL stuff with an EF at some point in the future. If so, it would be waste of time to retrofit DI into the DAL at this point, because it would all be thrown away in the end.
My conclusion
This is a judgment call. Your colleague is entitled to make it. I would focus on other, more obvious, lower-hanging fruit for refactoring.

Where should I create my DbContext among my services?

My application is built around "Services" like this:
public class ProfileService : BaseService {
private CommService _commService;
public ProfileService(CommService commService) {
_commService = commService;
}
public ApiResponseDto GetProfile(string profileUsername) {
using (var db = new appContext()){ db.DoStuff(); }
}
}
What I would like to do is push the db instantiation into BaseService, but I don't want to create a dbContext and incur the cost of such when I don't need it. So I'm thinking about doing something like this:
public class BaseService {
public AppContext _db;
public AppContext db(){
return _db ?? new AppContext();
}
}
And then all of my methods will access the db via db().DoStuff().
I don't like the idea of parentheses everywhere, but I like the idea of cleaning up my services footprints more.
My question is - if I create an instance of DbContext and don't use it, is there any cost? Or is the object just instantiated for future use? I hate to ask for opinions here as I know it's not allowed, but is this a step in the right direction of keeping things DRY?

Unit of Work Pattern
DbContext is effectively an implementation of the 'unit of work' pattern - once the DbContext is created, all changed done to the DbSet are then persisted in one go when you call SaveChanges.
So the further question you need to answer in order to properly answer your question is: What is the scope of the changes that make up your unit of work? In other words - what set of changes need to be made atomically - all succeed, or all fail?
A practical (if example of this - say you have an API endpoint that exposes an operation allowing the client to submit an order. The controller uses OrderService to submit the order, and then InventoryService to update the inventory associated with the items in the order. If each service has their own DbContext, you have a risk that the OrderService will succeed to persist the order submission, but the InventoryService will fail to persist the inventory update.
Dependency Injection
To combat this, a common pattern is to create a context per-request and let your IoC container create and dispose the context, and make it available to inject into services per request. This blog post gives a few options for DbContext management, and includes an example of configuring Ninject to do it.
What this means is your ctor will look like:
public ProfileService(CommService commService, AppContext context) {
_commService = commService;
_context = context;
}
And you can safely use the context there without having to worry about how it was created or where it came from.
Medhi's DbScopeFactory
However, my preferred approach for more complex applications is an excellent open source library documented up here: http://mehdi.me/ambient-dbcontext-in-ef6/. Injecting DbContext per request will work fine for simpler applications, but as your application gets more involved (e.g. multiple Contexts per application, multiple databases etc.), the finer grain control offered by his IDbContextScopeFactory is invaluable.
Edit to Add - Pros and Cons of Injection vs Construction
Following your comment asking for pros/cons of the approach you proposed, I'd say that generally, injection of dependencies (including DbContext) is a far more flexible and powerful approach, and can still achieve the goal of ensuring your devs don't have to be concerned with dbcontext lifecycle management.
The pros and cons are generally the same for all instances of dependency injection not just db context, but here are a few concrete issues with constructing the context within the service (even in a base service):
each service will have its own instance of the dbcontext - this can lead to consistency problems where your unit of work spans tasks carried out by multiple services (see example above)
It will be much more difficult to unit test your services, as they are constructing their own dependency. Injecting the dbcontext means you can mock it in your unit tests and test functionality without hitting the database
It introduces unmanaged state into your services - if you are using dependency injection, you want the IoC container to manage the lifecycle of services. When your service has no per-request dependencies, the IoC container will create a single instance of the service for the whole application, which means your dbcontext saved to the private member will be used for all requests/threads - this can be a big problem and should be avoided.
(Note: this is less of an issue if you are not using DI and constructing new instances of the services within controllers, but then you are losing the benefits of DI at the controller level as well...)
All services are now locked to using the same DbContext instance - what if, in the future you decide to split your database and some services need to access a different DbContext? Would you create two different BaseServices? Or pass in configuration data to allow the base service to switch? DI would take care of that, because you would just register the two different Context classes, and then the container would provide each service with the context it needs.
Are you returning IQueryables anywhere? If you are, then you run a risk that the IQueryable will cause the Db to hit even after the DbContext has gone out of scope - it may have been disposed by the garbage collector and will not be available.
From a dev perspective, I think nothing is simpler than the DI approach - simply specify the DbContext in your constructor, and let the DI container container take care of the rest.
If you are using DbContext per request, you don't even have to create or dispose the context, and you can be confident that IQueryables will be resolvable at any point in the request call stack.
If you use Mehdi's approach, you do have to create a DbContextScope, but that approach is more appropriate if you are going down a repository pattern path and want explicit control over the context scope.
As you can see, I'm far less concerned about the computational cost of constructing a DbContext when it's not needed (as far as I can tell, it's a fairly low cost until you actually use it to hit the db), and more concerned about the application architecture that permits unit testing and decoupling from dependencies.

Why does Microsoft warn from using PerRequestLifetimeManager

https://msdn.microsoft.com/en-us/library/microsoft.practices.unity.perrequestlifetimemanager(v=pandp.30).aspx states that:
Although the PerRequestLifetimeManager lifetime manager works correctly and can help in working with stateful or thread-unsafe dependencies within the scope of an HTTP request, it is generally not a good idea to use it when it can be avoided, as it can often lead to bad practices or hard to find bugs in the end-user's application code when used incorrectly. It is recommended that the dependencies you register are stateless and if there is a need to share common state between several objects during the lifetime of an HTTP request, then you can have a stateless service that explicitly stores and retrieves this state using the Items collection of the Current object.
What kind of bugs or bad practices is the warning refering to? How would one use it incorrectly? - Unfortunately the warning is not very specific and is therefore hard to apply to the real world. Furthermore it is not clear to me what stateful means in this context.
IMHO a typical scenario to use the PerRequestLifetimeManager would be some kind of database connection (e.g. DbContext) or similiar.

Its purpose would be to only instantiate one instance per request, which could (for example) prevent redundant operations and lookups during the course of a single request.
The danger is if someone assumes that the object created is a good place to store state during the request. The idea of dependency injection is that a class receives a dependency (commonly an interface) and doesn't "know" anything about it at all except that it implements that interface.
But someone could reason that if the object is going to persist throughout the life of the request then it's a good place to maintain state during the request. So they create a complex scenario where one class receives the dependency, stores some information in it (like setting a property), and then another class receives that same dependency and expects to read that property.
Now the purpose of dependency injection (decoupling) has been defeated because classes have built-in assumptions about what the lifetime of that dependency is, and may even include assumptions about what other classes have done or will do with the state of that object. That creates a tangled mess where the interaction between classes is difficult to perceive - even hidden - and so it's easy to break.
Let's say someone determines that the lifestyle of that dependency should be transient, not per web request. Suddenly all of the behaviors of those classes that depend on it stop working as expected. So developers look at those classes and see that nothing has changed. What happened? The interaction between those classes was hard to see in the first place, so when it breaks the problem will be hard to find. And if there was some valid reason why the lifestyle of that dependency was changed then the problem is going to be even harder to fix.
If we need to store state during a request then we should put it in "normal" places like in the HttpContext. There's still room there for some confusing practices and bugs, but at least we know that the HttpContext is (by definition) going to be tied to a particular request.

If I use an IocContainer at all, should it be used everywhere?

We use an Ioc Container to resolve most of the objects in a project, however it seems like it might be innappropriate to use it everywhere. At runtime, the user is in the context of a single company Id and it seems appropriate to me to pass that company Id in the constructor of, for example, a repository or unit of work. We could use a parameter override for the company Id at runtime, but is there any benefit in using
var uow = IocContainer.Resolve<IUnitOfWork>(new ParameterOverride("companyId", companyId))
as opposed to
var uow = new UnitOfWork(companyId)
OK, so I understand that I might want to create a different implementation of IUnitOfWork some time and I could then easily swap in the new implementation with Ioc configuration, but I am not convinced I will ever do that anyway.

No, there are times when calling new is exactly what you want. An example would be an object local to a method call or a narrow scope.
Model objects usually aren't under the control of an IoC container. You instantiate one for each new session or request scope, using data passed to you from users that can never be known by the IoC container on startup.
Update: Honza Brestan's point about logical units is spot on. The typical Spring layer arrangment is interface-based:
view->controller->service->persistence
Services use other services, model objects and persistence to fulfill use cases.

I find the biggest advantage of IoC not in the implementation swapping (people hardly do that anyway in most projects), but in forcing you to divide your code into clearer logical units, which in general means it is unit-testable, manageable and easier to reason about as a whole.
With that in mind, I suggest deciding the "injection granularity" for yourself depending on what are the logical units of your project. It may be 5 larger modules, it may be dozens of different small connectors. Also as duffymo mentioned, new may be what you want for local/narrow scope.

Is it necessary to implement IDisposable when using the Entity Framework in MVC?

I see in many examples about MVC, Repository pattern, Unit of Work and EF, for instance here, that both interfaces and classes implement the IDisposable interface. I guess this interface exposes just the method Dispose() with 2 overloads.
However in many other examples made by senior programmers, I do not see such implementation. Actually to me it seems quite logic that one a component is dismissed on every web request, since every request gets a brand new controller instance.
Or even if this is not the case, I guess by using a dependency injection framework such as Ninject, we delegate all this disposal tasks to the very framework.
It can also be the case that the implementation of IDisposable was required in older version of the EF or MVC framework.
Anybody might point me to the right direction?
UPDATE
The automatic disposal of the context can be seen in a layered application with Service and Repository layer. Assume that from both components we return IQueryable<T> objects, if we try to populate the objects from the controller, by iterating its items or call the ToList() method, we get a runtime error saying that the context is unreachable (closed)

The common pattern is to have an instance of the Repository in every Controller and to link the Disposal into the Dispose() of the Controller.
So I would say the pattern is generally required.
However in many other examples made by senior programmers, I do not see such implementation.
There are a few possibilities:
it is Demo code, error and resource handling omitted.
the pattern is implemented in a non obvious place (base class)
Point to a concrete example and we can find out.

Usually in most of the examples you can find on interner about Repository pattern using EF the Context has a Dispose method.
Now you don't strictly need to call the Dispose method on the Context but it may be a good practice for the reason below:
DataContext holds state (for example, a SqlConnection and pointers to the objects you have retrieved). These will eventually get cleaned up by the GC once you release all references, but some of these objects (for example, the underlying SqlConnection) may be holding resources that you typically want to release as soon as your are finished, rather than relying on the GC to clean up.
For lazy people: you can even wrap the context within a using statement which will call the dispose for you when the object get out from the scope of the using itself
more info at :
http://social.msdn.microsoft.com/forums/en-US/adodotnetentityframework/thread/2625b105-2cff-45ad-ba29-abdd763f74fe/
here you can also find an example that regarding Repository patter in EF
http://www.codeproject.com/Tips/309753/Repository-Pattern-with-Entity-Framework-4-1-and-C

With regards the connection state, EF is supposed to be quite good at only keeping the connection open only while it's needed (http://msdn.microsoft.com/en-us/library/bb896325.aspx). The link also shows how to get finer control over the connection state.