Home/ Questions/Q 9267129
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-06-18T14:28:42+00:00

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

  • 0

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.

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    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/

    • 0