Home/ Questions/Q 9195059
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-06-17T21:33:09+00:00

I am writing an application using WPF and the MVVM design pattern (I’m new

  • 0

I am writing an application using WPF and the MVVM design pattern (I’m new to the MVVM pattern too). This application manages and keeps track of films the user has watched. It also needs to contact external websites in order to download metadata for films. I’m doing this by using .NET TMDb and Rotten Tomatoes libraries.

Currently, I have a Movie class in the Models folder and that class contains all the properties of a film and the methods and logic required to set up the TMDb/RT library, search for matching results, and then download all the metadata. However, this is making my Movie class quite a bit more cluttered and heavy than what I think it should be.

Does it make more sense to move the methods and logic for accessing the third party APIs to the MovieViewModel or even another class altogether? How simple should the Model classes be?

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    How simple should the Model classes be?

    Usually, POCO-simple. It’s safe to think of model layer as of domain-objects definition + business logic. Domain objects will usually be simply data holders (like mentioned POCO classes) while business logic is anything that’s needed to perform your application’s requested functionality (data retrieval, persistence, communication with other APIs and so forth).

    ViewModel is glue that binds it all together and feeds to view.

    Does it make more sense to move the methods and logic for accessing the third party APIs to the MovieViewModel or even another class altogether?

    Yes. For the sake of separation of concerns, testability or generally not cluttering view model layer (model classes can be easily reused in view model when implemented correctly [POCO-correctly that is]).

    Also, consider separating your model even further:

    Model.Entities -- POCO domain objects
Model.Contract -- interfaces for your business logic
Model.*        -- concrete implementations of above

    This has multiple advantages:

    • Your entities (domain objects) are not mixed up with data access layer (which tends to be common abuse). As a result, it’s very easy to replace data layer or add new database support,
    • Entities assembly is easily reusable in other projects due to its simplicity (remember, POCOs only),
    • View models need to know about entities and contracts assemblies only – they stay clean and once again it’s easy to replace/reuse implementations,
    • Your project will stay loosely coupled, modular and flexible.

    Overall, minor mistakes (or casual laziness) when designing/implementing model layer will snowball terribly at later stages of the project. Pulling entire DAL to VM, linking 3rd party API assemblies to VM (“because the slipped with model code”), impossibility to write unit tests are all outcome of poor layers design. As a result, instead of reusable view models you end up unmaintainable monsters which everybody’s afraid to touch.

    • 0