Which Pattern to choose ? Asp.net Mvc 4

Question

I'm really confused, I learned with the book "Apress pro Asp.net Mvc 4", that the best pattern for Mvc 4, is the Dependency Injection, ( to put the Model data of the database etc... in another project (Domain) and then create interfaces and implementation to those interfaces, and then connect it to the controller with Ninja..

And all the connect to the db is only from the data-layer solution, the only model in the 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 the other hand, In my last job(webmaster) , the company used another pattern for the mvc Projects (I'm using this pattern right now).

the projects is made with only One Solution and using Static Classes to handle the data layer

I don't like the Dependency Injection, this is too complicated, and by 'f12' you see only the interface instead of the Concrete class

Some questions:

1. which patter is better for performance (fast website)?
2. is't good to use " public Db db = new Db();" in the controller, instead of use it only in the domain layer (solution)??
3. What is the advantages of using Dependency Injection? is't bad to use my pattern?
4. What is the advantages of split the project into 2 solutions for the 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");
        }
    ...
}

Answer 1

which patter is better for performance (fast website)?

Impossible to answer. You could have non-performant code in either of these approaches. Don't try to prematurely optimize for performance, optimize for clean and supportable code and address performance bottlenecks that are actually observed in real scenarios.

is't good to use " public Db db = new Db();" in the controller, instead of use it only in the domain layer (solution)

It's a question of separating concerns and isolating dependencies. If your controller internally instantiates a connection to a database then that controller can only ever be used in the context of that database. This will make unit testing the controller very difficult. It also means that replacing the database means modifying the controller, which shouldn't need to be modified in that case.

Dependency injection frameworks are simply a way of addressing the Dependency Inversion Principle. The idea is that if Object A (the controller) needs an instance of Object B (the database object) then it should require that the instance be supplied to it, rather than internally instantiate it. The immediate benefit here is that Object B can just be an interface or abstract class which could have many different implementations. Object A shouldn't care which implementation is given to it, as long as it satisfies the same observable behavior.

By inverting the dependency (whether or not you use a dependency injection framework), you remove the dependency on the database from the controller. The controller just handles client-initiated requests. Something else handles the database dependency. This makes these two separate objects more portable and re-usable.

What is the advantages of using Dependency Injection? is't bad to use my pattern?

See above. Dependency injection is a way to achieve inversion of dependencies, which is the core goal in this case. Note that there are a few different ways to achieve this. Some frameworks prefer constructor injection, some support property/setter injection, etc. Personally I tend to go with the service locator pattern, which has the added benefit of being able to abstract the dependency of the dependency injector itself.

It's only "bad" to use your approach if you run into any problems when using it. There are good patterns to address various concerns, but if your project doesn't legitimately have those concerns then using those patterns would be over-engineering and would actually hurt the supportability of the code. So, as with anything, "it depends."

What is the advantages of split the project into 2 solutions for the Data Layer?

Two solutions? Or two projects in the same solution? (Resulting in two assemblies.) The advantage is that you can re-use one without having a dependency on the other. For example, in some of the code you posted there is an allusion to the repository pattern. If you have an assembly which serves only the purpose of implementing repositories to the back-end data then any application can use those repositories. If instead it's all implemented in the MVC application directly then no other application can use it, it's tightly coupled to the MVC application.

If you will never need to re-use that functionality, then this isn't the end of the world. If you would like to re-use that functionality, separating it into a portable assembly which internally isolates its dependencies would allow for that.