Question

1. Whats the difference between Model and ViewModel? I should use both of them or I better skip one of them? who grabs the data from the database?

2. I wonder whats the best/right way to take my data from the database.

One option is to have a DAL (Data Access Layer) and instantiate it in every controller,
fill with it the viewmodels like:

var viewmodel = Dal.GetArticles();

Another option is to let the model itself grab the information from the Database:

var model = new ArticlesModel();
model.GetArticles();

public void GetArticles()
{
var context = new DbContext();
_articles = context.Articles
}

Another similar option is to have a static DAL so you can access it inside every model,
so each model will have a method to grab the data using the static DAL class (Which contain a DbContext class inside to access the Database)

public void GetArticles()
{
_articles = DAL.GetArticles();
}

So the general question is if the model itself needs to grab the data from the database or the controller itself can have access to the DAL.

Answer 1

While someone is writing a more useful answer, I will quickly address your points.

Model is the data you want to display.

More often than not, you will want to use object relational mapping so most of your business object classes correspond to database tables and you don’t have to manually construct queries.

There are plenty of ORM solutions available, including Entity Framework, NHibernate and (now dying) LINQ to SQL.

There is also an awesome micro-ORM called Dapper which you may like if bigger frameworks feel unneccessarily bloated for your solution.

Make sure you learn about the differences between them.

DAL is more idiomatic in .NET than classes that “know” how to load themselves.

(Although in practice your solution will very likely be a mixture of both approaches—the key is, as usual, to keep the balance.)

My advice is to try keeping your models plain old CLR objects as long as your ORM allows it and as long as this doesn’t add extra level of complexity to the calling code.

These objects, whenever possible (and sensible—there are exceptions for any rule!), should not be tied to a particular database or ORM implementation.

Migrating your code to another ORM, if needed, will be just a matter of rewriting data access layer.
You should understand, however, that this is not the main reason to separate DAL.

It is highly unlikely you’ll want to change an ORM in the middle of the project, unless your initial choice was really unfit for the purpose or you suddenly gained a traction of 100,000 of users and your ORM can’t handle it. Optimizing for this in the beginning is downright stupid because it distracts you from creating a great product capable of attracting even a fraction of hits you’re optimizing for. (Disclaimer: I’ve walked this path before.)

Rather, the benefit of DAL is that you database access becomes always explicit and constrained to certain places where you want it to happen. For example, a view that received a model object to display will not be tempted to load something from the database, because in fact it is the job of controller to do so.

It’s also generally good to separate things like business logic, presentation logic and database logic. Too often it results in better, less bug-ridden code. Also: you are likely to find it difficult to unit-test any code that relies on objects being loaded from the database. On the other hand, creating a “fake” in-memory data access layer is trivial with LINQ.

Please keep in mind that again, there are exceptions to this rule, like lazy properties generated by many ORMs that will load the associated objects on the go—even if called within a view. So what matters is you should make an informed decision when to allow data access and why. Syntaxic sugar might be useful but if your team has no idea about performance implications of loading 20,000 objects from ORM, it will become a problem.

Before using any ORM, learn how it works under the hood.

Choosing between Active Record-style objects and a DAL is mostly a matter of taste, common idioms in .NET, team habits and the possibility that DAL might eventually have to get replaced.

Finally, ViewModels are a different kind of beast.

Try to think of them like this:

1. You shouldn’t have any logic in views that is more sophisticated than an if-then-else.
2. However, there often is some sophisticated logic in showing things.
   Think pagination, sorting, combining different models in one view, understanding UI state.

These are the kinds of thing a view model could handle.
In simple cases, it just combines several different models into one “view-model”:

class AddOrderViewModel {
    // So the user knows what is already ordered
    public IEnumerable<Order> PreviousOrders { get; set; }
    // Object being added (keeping a reference in case of validation errors)
    public Order CurrentOrder { get; set; }
}

Models are just data, controllers combine the data and introduce some logic to describe data to be shown in view models, and views just render view models.

View model also serves as a kind of documentation. They answer two questions:

1. What data can I use in a view?
2. What data should I prepare in controller?

Instead of passing objects into ViewData and remembering their names and types, use generic views and put stuff in ViewModel‘s properties, which are statically typed and available with IntelliSense.

Also, you’ll likely find it useful to create ViewModel hierarchies (but don’t take it to extremes!). For example, if your site-wide navigation changes from breadcrumbs to something else, it’s cool to just replace a property on base view model, a partial view to display it and the logic to construct it in the base controller. Keep it sensible.