Where does business logic sit in MVVM?

Question

I am used to developing with N-Tier architecture, i.e. Data Access Layer, Business Logic Layer, etc

Can anyone provide any advice or links about the best location for my business logic?

Do I put all of this into classes within the Models folder of my Silverlight application?

Paul

Hi Paul. Think of MVVM as a Pattern for UI Design and Interaction with a specific Platform (Silverlight in your case). The N-Tier Architecure with Business Domain remains the same way you are familiar with — flo scheiwiller, Jun 09 '12 at 19:51

score 20 · Accepted Answer · answered Jun 09 '12 at 19:41

20

Business logic, as well as the data, is typically part of the Model layer in MVVM. The View is the visuals, and the ViewModel is the "glue" that lets you work with the business specific logic and data.

Anything that's specific to the domain or business should be reusable by other applications, using other architectures.

answered Jun 09 '12 at 19:41

Reed Copsey

554,122
78
1,158
1,373

ok thanks I have a lot of C# code built for a normal C# site, if I wanted to use this, I assume I would just add references to it, or is not possible as its in .NET not Silverlight? – Paul Jun 09 '12 at 19:43
1

@Paul You'd need to rebuild it for silverlight, or use the PCL to compile it so it works with both. See: http://msdn.microsoft.com/en-us/library/gg597391.aspx – Reed Copsey Jun 09 '12 at 19:45

score 3 · Answer 2 · answered Jun 11 '12 at 09:34

3

That's a good question, the answer will partly be a matter of the project's complexity and of developer's taste.

Some MVVM projects I have seen put everything in the VM part, so the View's .cs files are empty (because everyone knows 'code-behind' is evil </sarcasm>) and the Model files contain passive 'storage classes' (ie C structs with encapsulation basically).

It can be a decent choice for some simple projects (like a viewer with barely any logic). But it will lead to blob-like View Models trying to do everything, which is unmanageable, if your project has any complexity.

Reed Copsey's answer (business logic/data access should be decoupled of View/ViewModel) is the best solution for projects with any significant complexity.

answered Jun 11 '12 at 09:34

jv42

8,521
5
40
64

This is going to be a complex system where I need logic to be shared amoungst areas of the system. I hate duplicating code as well so I think I will try my best to keep View Models simple, just out of interest what do you think are examples of things that people traditionally bloat the view model in but should really be in the model itself? – Paul Jun 11 '12 at 23:32
All kind of logic can be found in VM, conversions, validation, persistence, business rules, whatever. And lots of View stuff too, like showing/hiding parts, etc... – jv42 Jun 12 '12 at 14:23

score 3 · Answer 3 · edited Feb 18 '15 at 16:01

I faced the same problem and decided to go this way: I created classes like controllers in MVC (performing some actions with my model) and I work with them in all ViewModels.

For example: our application has a list of books. We need to add/edit/delete them.

So we have a model:

public class Book 
{
    public int BookId { get; set; }
    public string Title { get; set; }
    public string Author { get; set; }
}

Then we have a controller class:

public class BookController 
{
    string dbPath = ...;

    public void AddBook(string title, string author)
    {
        var book = new Book() { Title = title, Author = author };
        AddBook(book);
    }

    public void DeleteBook(int id)
    {
        using (var db = new SQLiteConnection(dbPath))
        {
            db.Delete<Book>(id);
        }
    }

    public void DeleteBook(Book book)
    {
        using (var db = new SQLiteConnection(dbPath))
        {
            DeleteBook(book.BookId);
        }
    }

    public List<Book> GetAllBooks()
    {
        using (var db = new SQLiteConnection(dbPath))
        {
            return db.Table<Book>().ToList();
        }
    }

    public Book FindBook(string title, string author, int id)
    {
        .....
    }
}

Now we can use it wherever we need, e.g.:

public class BookListViewModel : ViewModelBase 
{
    public BookListViewModel() 
    {
        GetData();    
    }

    private void GetData()
    {
        BookController bc = new BookController(); // here we start using our controller. 
        _books = new List<Book>();
        _books = bc.GetAllBooks();
     }
}

Such approach helps us:

keep all business logic separately (in controller class)
avoid code duplication

Where does business logic sit in MVVM?

3 Answers3

Linked