MVVM with LinqToSQL

Question

Hello Together,

there a little BrainF*** question for me to understand MVVM in relation to LinqToSQL.

The MVVM is build like:

View --> Viewmodel --> Model

View: the xaml and the cs code behind file. right ?

Viewmodel: created by the Developer (*.cs), encapsulated properties of my Model

Model: Datamodel

So here is the Question:

the LinqToSql gives me an dbml file which contains all Data from my Database, so can i use this as the Model ?

Where and how must i implement the Commands in this architecture ?

Where are the methods to get data from the database and fill the viewmodel or model ? :-) like getCustomer()

Answer 1

It is basically your repositories that act as your data source, and this is where you write your methods like:

public class CustomerRepository{
    private MyDataContext db = new MyDataContext();
    public Customer Find(id)
    {
      //Linq queries or Lambdas
    }

    public Customer Add(Customer _custoemr){}

    public void save(){}

    public IEnumerable<Customer> FindAll(){}
}

in this question you can find some useful links that can help you understand the repository pattern.

Answer 2

You're asking a bunch of questions here, but let's tackle them one at a time:

View: the xaml and the cs code behind file. right ?

Yes. Or, in general, all logic that is concerned only with presenting data. Examples:

• Given a list of things, it's up to the View layer to decide if they'll be displayed in a dropdown box or a bulleted list.
• It's up to the View to decide if Employees who are Managers get their names coloured blue. But it is not up to the view to decide if an Employee is a Manager.

the LinqToSql gives me an dbml file which contains all Data from my Database, so can i use this as the Model ?

Yes, you can. The LINQ-to-SQL classes created underneath the DBML file present you with an object model built from your database schema. You can extend these objects (with partial classes, or by building other classes composed of them) to add validation and other business logic. Scott Guthrie gives us the low-down.

These are the classes that your ViewModels will typically encapsulate, adding and exposing properties that are relevant to the Views which display the data.

Where and how must i implement the Commands in this architecture ?

Commands are a loosely-coupled means of communicating between your user interface and and event handling logic. So your ViewModels will expose Commands to the Views. You specify what Command a given event on a given control (Such as Button.Click) should emit, and the associated ViewModel handles the rest.

Where are the methods to get data from the database and fill the viewmodel or model ? :-) like getCustomer()

This is what the Repository pattern is for. In brief: You build a Repository class that uses the DataContext specified in your DBML file to submit LINQ queries to the database and return Model objects. Your ViewModels can use instances of your Repository class to retrieve the Models that they will in turn present to your Views.

Please note I've only outlined a few basics, and this certainly isn't the only way to use the broad patterns you've mentioned. Josh Smith has written tons of great material on these concepts. WPF Apps With The Model-View-ViewModel Design Pattern would be a good place to start!