How to connect mvc application using entityframework or ado.net

It depends a bit on how much abstraction you need. Everything is a compromise; for example, EF and NHibernate introduce great flexibility for representing the data in interesting and exotic models - but as a result they do add overhead. Noticeable overhead.

If you don't need to be able to switch between database providers, and different per-client table layouts, and if your data is primarily read, and if you don't need to be able to use the same model in EF, SSRS, ADO.NET Data Services, etc - then if you want absolute performance as your key measure you could do far worse than look at dapper. In our tests based on both LINQ-to-SQL and EF, we find that EF is significantly slower in terms of raw read performance, presumably due to the abstraction layers (between storage model etc) and materialization.

Here at SO, we are obsessive-compulsive about raw performance, and we're happy to take the development hit of losing some abstraction in order to gain speed. As such, our primary tool for querying the database is dapper. This even allows us to use our pre-existing LINQ-to-SQL model, but simply: it is heaps faster. In performance tests, it is essentially exactly the same performance as writing all the ADO.NET code (parameters, data-readers etc) manually, but without the risk of getting a column name wrong. It is, however, SQL based (although it is happy to use SPROCs if that is your chosen poison). The advantage of this is that there is no additional processing involved, but it is a system for people who like SQL. Which I consider: not a bad thing!

A typical query, for example, might be:

int customerId = ...
var orders = connection.Query<Order>(
    "select * from Orders where CustomerId = @customerId ",
    new { customerId }).ToList();

which is convenient, injection-safe, etc - but without tons of data-reader goo. Note that while it can handle both horizontal and vertical partitions to load complex structures, it will not support lazy-loading (but: we're big fans of very explicit loading - fewer surprises).

Note in this answer I am not saying that EF isn't suitable for high-volume work; simply: I know that dapper is up to it.

EDIT: To summarise, I think understand where you're coming from - at first glance, the ASP.Net MVC framework seems to have (too) many parts, and it's difficult to start understanding it. Having said this, I'd argue that you're looking at this wrong. ASP.Net MVC is not a particularly heavy MVC framework (you should compare it to PHP MVC frameworks to be fair), but yes, it is very much conventions-based. There is a lot of good reasoning behind that design choice, and your first priority in learning the framework would be to learn its conventions, and perhaps the reasoning for them. If for some reason you absolutely want to go deeper, the framework is open source, and you can dig into it here.

I can just skip frameworks altogether, and toss random PHP along with my HTML on a single file and make it work

Well, not with an MVC framework (even in PHP). You're going to at least have a model, a view, and a controller. Those are a bit of a minimum, so I'm not really sure what you're looking for here; it's an apples and oranges comparison.

After that, there's going to be a few other files that you will probably need; such as configuration for the routing, etc. This is fairly standard and comparable to PHP MVC frameworks.

If you want a "single page" model, you could try WebForms, although that technology typically tries to move logic into a separate "code behind" page. I'm pretty sure you could skip the latter, however, and have .aspx files logically identical to .php files sitting there.

Do I really need to create a whole bloat of files and folders...

The default VS project template does tend to copy a lot of potentially unnecessary stuff (scripts, etc), but you could remove most of those. Again, you will probably have a minimum number of things there. Do these really cause you major worry? Have you seen what a Symfony installation looks like?

... for the sake of convention?

Convention is a great thing. The concept is called "convention over configuration", and for most non-trivial projects, it is wonderful thing. It stops people from reinventing things, and gives standards that should be followed.

Since you mention this is a learning exercise, I would suggest that you stop worrying about these things too much. ASP.Net MVC is very much about convention, and you are doing yourself a disservice by trying to work around those. In fact, to learn MVC, you should learn the conventions as much as any of the internals.