MVC as a Hot Paradigm

Question

The Stack Overflow guys themselves on the Podcast mention how MVC is the new hot thing; .Net (presumably 4.0 will have it standard), Rails, & Django.

But I want to know what is the big deal.

It reminds me of asp/jsp from 2000 - interspersing lots of Request and Response commands with HTML.

And I don't see why actually writing SQL in SQL Server or MySQL is that painful, nor do I understand the benefits of ORM, LINQ, and so forth.

For me, the most complicated thing has never been retrieving, entering, managing, or creating data, but using AJAX to an extent of really making a rich front-end.

Can someone enlighten me as to why MVC is so hot and preferable to .Net 3.0 where the majority of my code and time is spent not in data management, but it front-end work?

Jonathan

Answer 1

The biggest benefit to me is the clear separation of concerns when you go with MVC. This is very difficult to accomplish in traditional webforms programming.

Also the unit testing benefits are really nice.

Answer 2

Today apps are becoming more and more complex (both from business logic & UI logic perspective). These tools and patterns help deal with this complexity (which is effectively what Software Development is about): they help manage essential complexity without introducing a large amount of accidental complexity.

Answer 3

From here:

Successful use of the pattern isolates business logic from user interface considerations, resulting in an application where it is easier to modify either the visual appearance of the application or the underlying business rules without affecting the other.

Classic ASP.NET web development is highly coupled, wich makes very difficult to modify anything in isolation and to easily apply any automatic testing methodology. With MVC you can really apply principles like DRY and techniques like TDD.

Answer 4

The whole idea is to seperate the business logic (model) from the UI's (view) from the methods of communication and data-transfer between the two (controller).

This way, business logic programmers can focus on writing bug-free logical modules and designers can focus on building usable UIs. If the MVC design is good, you should be able to just 'plug' these two together through a controller and rely on the contracts established between each layer to make sure it all works.

Should any layer ever need to be refactored or replaced, the process is much easier, since the other layers can be utilized without many changes.

Answer 5

And I don't see why actually writing SQL in SQL Server or MySQL is that painful, nor do I understand the benefits of ORM

SQL is not composable. ORM conditions typically are.

preferable to .Net 3.0 where the majority of my code and time is spent not in data management, but it front-end work

I've done both .NET and Rails, and I suspect this is a symptom of .NET being so verbose for front-end work. In more concise frameworks, the front-end is so small that writing SQL is a bottleneck.

Answer 6

MVC is nothing new as a design pattern and framework for multi-tiered apps. It obviously makes sense to separate your data from your view and to delegate the accesses to a controller. Its not so much about managing complexity as it is about reusability and maintaining the code base. It much easier for any individual to work on the codebase if it follows an mvc pattern. Much smarter people can give you a more in-depth explanatioin as to it's merits. I gues I'm not understanding why MVC would be mutually exclusive with net 3.0?

Answer 7

I recently switched over to MVC and I have had a mixed experience but I am glad I made the switch.

The biggest hurdle was that even though a new MVC project is purportedly ready to run and you can start building on top of it iteratively, I actually had to build a lot of scaffolding for a real application and do a lot of reading/learning.

I chose Entity Framework (EF) which caused a lot of grief initially until I got EFPocoAdapter to do a lot of what I wanted (which is being deprecated because it is transitionary and will find itself merging into EF 4.0). In the process I had to learn about Persistence Ignorance, Inversion of Control, brush up on SOLID principles and then learn about the MVC architecture itself. I am currently re-reading Head First Design Patterns because I never fully utilized those patterns until now.

I ran into serialization issues with circular references in object graphs, entity vs POCO objects and persisting data from the client and back into the database. I really am starting to get what REST is about and getting into the guts of HTTP and rooting for HTML5 (PUT/DELETE support).

I also became familiar with ORMs which I had never used before. I learnt and am still learning Linq (query expressions) and about expression trees. I got first hand experience with a lot of C# 3.0 features I had only read about (object initializers, anonymous types, implicit typing and most of the others).

Within ASP.NET MVC itself I have enjoyed writing action filters and custom routing constraints, striking a balance between model and controllers, pondering over domain objects, struggling with POCO and Persistence Ignorance and writing a lot of AJAX code.

As a web developer I have thoroughly enjoyed it. In the process I have also gained a lot of respect for the Ruby on Rails and Java communities as I realize their prowess with MVC, DDD and ORMs (not to mention some great open-source initiatives as well).

Unless you get your hands dirty you really won't appreciate what it's all about. Do it as a hobby and give it a month. I can promise you that you'll be a much better developer than you are now and you'll really appreciate most if not all of the stuff. It's really a paradigm shift that has already been taking place in RoR/Java communities and .NET is just catching up to now.