How to avoid code duplication in MVVM?

Question

This question is similar to Where does business logic sit in MVVM?

However, I didn't want to create a comment chain on that one

Lets say for example that I have a table of invoices and I want to get this data and perform some apportionment on it ready for use in 2 totally separate reports and 3 screens.

In our current web application I would have put this in the Data Service Layer, and all of my reports and screens would have called this

In MVVM people seem to suggest that the model should not be bloated out and that logic should be put in the view models. But in this case I be duplicating the code 5 times?

In his answer to my other question Reed states "Anything that's specific to the domain or business should be reusable by other applications, using other architectures."

Can Reed or someone clarify what my approach should be? Can MVVM be combined with other architectures?

I am using Silverlight 5 with the Simple MVVM Toolkit

Paul

Could one not establish a "helper" class or an object that would handle a common input for the reports, and output a common object that you could code ViewModels against? — Urda, Jun 19 '12 at 16:36
ok thanks so this would sit in a helpers folder in the silverlight application yeah? — Paul, Jun 20 '12 at 06:30
ohh easy way is you can use common context like make one class and defined all method whichever you want then create that class object at first time like in viewmodellocator then you can use same context for whole application and u don't need to write all that method again just use that object — Dhaval Patel, Oct 11 '12 at 15:30

score 0 · Answer 1 · edited Jun 21 '12 at 19:31

0

The ViewModel is not for business logic. It is for user interface logic. As its name is given, it is representing the View. If you have five different reports that presents similar data, give this data a name and make all five ViewModels understand how to work with the data objects.

Since we are talking about reports, data is understood to e only displayed. The ViewModel can just be a simple data source with minimal user interface interaction, basically a very thin layer.

edited Jun 21 '12 at 19:31

Urda

5,460
5
34
47

answered Jun 20 '12 at 05:13

Chen Kinnrot

20,609
17
79
141

Where in my silerlight application would this data sit for the view model to get? Would I have a folder called services? – Paul Jun 20 '12 at 06:30

score 0 · Answer 2 · answered Apr 02 '13 at 14:35

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&lt;Book&gt;(id);
            }
        }
public void DeleteBook(Book book)
{
            using (var db = new SQLiteConnection(dbPath))
    {
                DeleteBook(book.BookId);
            }
        }
public List&lt;Book&gt; GetAllBooks()
{
            using (var db = new SQLiteConnection(dbPath))
    {
                return db.Table&lt;Book&gt;().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();

}
void GetData()
{
            BookController bc = new BookController(); // here we start using our controller. 
            _books = new List&lt;Book&gt;();
            _books = bc.GetAllBooks();
        }
    }

Such approach helps us:

1) keep all business logic separately (in controller class)

2) avoid code duplication

How to avoid code duplication in MVVM?

2 Answers2