Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Why is .Net MVC architecture so overcomplicated vs Rails? [closed]

Note: This is far from a post on x is better than x. Pleased dont go there.

I'm a .Net guy and always have been, I've used the MVC framework since early version 2 Betas and every version since. Over the past few months I've been messing around with Rails and I have a question about architecture that seems to differ hugely between the 2 platforms. (Based on the community and questions on sites such as SO)

In .Net MVC we are encouraged to separate concerns, create separate projects to handle Data Access, Business Logic and the View, we are also told that we should convert our Data objects to ViewModels before they hit the view etc

In Rails, things seem allot simpler, we have an object that contains Validation, DataAccess (Via active record) and other logical properties and we simply ship that to the View and display it.

So why in one framework is this methodology acceptable and in the other it's deemed wrong and we all end up writing more code and creating more files.

Note : I'm no Rails expert and I really am not trying to compare which is better than x, I am looking at the high level architecture of the 2 frameworks and working out what it's acceptable in one but not the other.

like image 973
LiamB Avatar asked Feb 08 '13 14:02

LiamB


People also ask

Is MVC pattern still used?

Today the MVC pattern is used for modern web applications because it allows the application to be scalable, maintainable, and easy to expand.

Is MVC deprecated?

The MVC architectural pattern ruled the software world in the past twenty or so years. It is simple: you never mix your data with the display of them.

Why we go for MVC instead of ASP Net?

Testability-ASP.NET MVC framework provides better testability of the Web Application and good support for the test driven development too. Lightweight-ASP.NET MVC framework doesn't use View State and thus reduces the bandwidth of the requests to an extent.


1 Answers

It depends on what type of application you are developing and how much you expect it to grow.

For trivial applications there is no need to complicate things with different view and domain models (but you might want to use seperate view models and entities: http://blog.gauffin.org/2011/07/three-reasons-to-why-you-should-use-view-models/).

For CRUD applications you don't have to wrap your data access in an abstraction such as repository pattern.

But if you expect to code anything other than trivial or CRUD applications I encourage you to do so. Patterns and principles aid you the day you want to start to maintain your application. You get smaller more well defined classes and the business logic is made in one place instead of all over your application.

I've written a small blog entry about why I use abstractions: http://blog.gauffin.org/2013/01/data-layer-the-right-way/

And why encapsulation is important: http://blog.gauffin.org/2012/06/protect-your-data/

like image 58
jgauffin Avatar answered Sep 20 '22 14:09

jgauffin