Which Pattern to choose ? Asp.net Mvc 4 -

i'm confused, learned book "apress pro asp.net mvc 4", best pattern mvc 4, dependency injection, ( put model data of database etc... in project (domain) , create interfaces , implementation interfaces, , connect controller ninja..

and connect db data-layer solution, model in web solution in viewmodel

the controller

public class productcontroller : controller {      private iproductrepository repository;      public productcontroller(iproductrepository productrepository)     {         this.repository = productrepository;     }     .... } 

and ninject

 ninjectkernel.bind<iproductrepository>().to<efproductrepository>(); 

and on other hand, in last job(webmaster) , company used pattern mvc projects (i'm using pattern right now).

the projects made 1 solution , using static classes handle data layer

i don't dependency injection, complicated, , 'f12' see interface instead of concrete class

some questions:

1. which patter better performance (fast website)?
2. is't use " public db db = new db();" in controller, instead of use in domain layer (solution)??
3. what advantages of using dependency injection? is't bad use pattern?
4. what advantages of split project 2 solutions data layer?

example:

 public class languagecontroller : admincontroller     {          public db db = new db();          protected override void dispose(bool disposing)         {             db.dispose();             base.dispose(disposing);         }          //         // get: /admin/language/         public actionresult index()         {             return view(db.languages.tolist());         }          [httppost, actionname("delete")]         [validateantiforgerytoken]         public actionresult deleteconfirmed(short id)         {             language language = db.languages.find(id);             db.languages.remove(language);             db.savechanges();             return redirecttoaction("index");         }     ... } 

which patter better performance (fast website)?

impossible answer. have non-performant code in either of these approaches. don't try prematurely optimize performance, optimize clean , supportable code , address performance bottlenecks observed in real scenarios.

is't use " public db db = new db();" in controller, instead of use in domain layer (solution)

it's question of separating concerns , isolating dependencies. if controller internally instantiates connection database controller can only ever used in context of database. make unit testing controller difficult. means replacing database means modifying controller, shouldn't need modified in case.

dependency injection frameworks way of addressing dependency inversion principle. idea if object (the controller) needs instance of object b (the database object) should require instance supplied it, rather internally instantiate it. immediate benefit here object b can interface or abstract class have many different implementations. object shouldn't care implementation given it, long satisfies same observable behavior.

by inverting dependency (whether or not use dependency injection framework), remove dependency on database controller. controller handles client-initiated requests. else handles database dependency. makes these 2 separate objects more portable , re-usable.

what advantages of using dependency injection? is't bad use pattern?

see above. dependency injection way achieve inversion of dependencies, core goal in case. note there few different ways achieve this. frameworks prefer constructor injection, support property/setter injection, etc. tend go service locator pattern, has added benefit of being able abstract dependency of dependency injector itself.

it's "bad" use approach if run problems when using it. there patterns address various concerns, if project doesn't legitimately have concerns using patterns over-engineering , hurt supportability of code. so, anything, "it depends."

what advantages of split project 2 solutions data layer?

two solutions? or 2 projects in same solution? (resulting in 2 assemblies.) advantage can re-use 1 without having dependency on other. example, in of code posted there allusion repository pattern. if have assembly serves purpose of implementing repositories back-end data application can use repositories. if instead it's implemented in mvc application directly no other application can use it, it's tightly coupled mvc application.

if never need re-use functionality, isn't end of world. if re-use functionality, separating portable assembly internally isolates dependencies allow that.