Is ASP.NET MVC slow as compared to traditional approach?

Question

I create three folders in the Project Explorer of any IDE that I use. I name them: App Layer, Business Layer and Data Layer. The App Layer holds all the UI stuff, the Business Layer holds all the classes dealing with business logic and the Data Layer holds the classes for DB connectivity and queries.

I am new to MVC pattern and when I attempted it on VS2010 with ASP.NET, I found it far more complicated with all sorts of nested folders created. I was already separating the logic and the UI in my old style. What differed in the MVC is that you can use Routing to directly call methods via URL (Correct me if I am wrong), but in that case I assume the performance of the MVC application slows down. It is just an overhead to call a method via URL and than the method queries the DB.

Isn't the performance of ASP.NET MVC a bit slow? Even though manageability is good but the learning curve is also very steep?

Answer 1

This is a very subjective question in some respects, but I will attempt to answer the parts that can be reasonably answered.

Isn't the performance of MVC a bit slow?

No. Of course, it is possible through a really poor implementation of the pattern to cause it to perform poorly (but that is true of anything and everything), but the pattern itself is not inherently slow in any regard. The mapping of URLs to methods of controller classes is utterly trivial and there's no reason for it not to have excellent performance.

Yes, there will be a small amount of overhead, but there are different kinds of overhead with with traditional ASP.NET or PHP applications too. Don't pre-optimize. Instead, choose the framework/tools that make you perform better.

The learning curve is also very steep?

Your learning curve is different than everybody elses, but in my personal experience, it was quite the opposite. With both Ruby on Rails and ASP.NET MVC, I found that the MVC pattern so obviously and intuitively matched the nature of web applications that the learning curve was virtually non-existent. Rather, I was disappointed with myself for not having been the one who though of it.

Answer 2

ASP.NET MVC is what you call the "App Layer".

So you should still create 3 folders App layer, Business layer and Data layer of which the latter two would exactly contain what they would contain in other projects of yours.

The App layer folder would then contain the whole ASP.NET MVC project with all its sub-folders (models, controllers, content, scripts, ...).

So concerning performance, I don't think it really matters. You would never use "Routing" for invoking a Business layer or Data layer method. You only use "Routing" for invoking controller methods, so for your UI (the App layer in your terminology). You would then invoke your Business Layer methods from your controllers, so that would happen with the same performance like other projects of yours.

Answer 3

Layering and organization has always some costs. If you really need performance, you should check where and if its worth and if so:

• start removing layers
• when there are no more layers, start removing methods
• if there are no methods, think about c

In the worst of all cases you'll end up with an increibly performant code that you can only understand and with approaching 0 portability or flexibility.