1

I'm over-thinking this and getting myself into a muddle but can't clear my head.

I'm new at WPF and I'm trying to get familiar with MVVM. I understand the theory. I need a view, a model and another model (called the view-model).

However, what happens if my model is constructed by a parameter of the View's constructor.

So, assuming I have a totally empty project, the only thing is I've an overloaded MainWindow constructor which takes the model:

public MainWindow(Logging.Logger logFile)
        {
            InitializeComponent();
            this.DataContext = logFile;
        }

The Model is the logFile. Can I still implement the MVVM when I don't have a separate Model class?

Any thoughts would be appreciated.

Dave
  • 8,163
  • 11
  • 67
  • 103

3 Answers3

3

You're overthinking this.

There are several components to MVVM:

View:

The view provides a, well, view on the data. The view gets its data from a viewmodel

ViewModel:

The viewmodel is there to organise your data so that you can organise one or more sources of data into a coherent structure that can be viewed. The viewmodel may also perform basic validation. The ViewModel has no understanding of the UI so should not contain references to controls, Visibility, etc. A viewmodel gets its data from services.

Services:

Services provide data from external sources. These can be WCF, web services, MQ, etc (you get the idea). The data the service returns may need to be shaped so that it can be displayed in the UI. To do this you would take the raw data from the service and convert it to one or more Model objects.

Model:

A model object is an object that has been created so that it can be easily displayed/work with the UI.

You may find that you don't need to shape your data coming from your services (lucky you), in which case there's no need to create model objects. You may also decided that you don't want your services talking directly to your viewmodels but instead what to have them get their data via a "mediator" object. That's also good in some situations (usually when you're receiving a continuous stream of data from a source/multiple sources).

MVVM is a bit like porridge: there are lots of potential garnishes you can add, but you don't necessarily need to add them all. Or want to.

Does this help?

Edit: just stumbled on this: a more in-depth expression of what MVVM is:Mvvm Standardisation. This may also be useful

Community
  • 1
  • 1
Faster Solutions
  • 7,005
  • 3
  • 29
  • 45
  • My services is provided via the constructor of the UI since the logFile is an in memory only object. Maybe I need to save the log file to XML prior and call it as a service? – Dave Oct 15 '12 at 06:03
  • At the moment, nothing like that at all - it's a straight forward WPF project and several class libraries - I don't use a database or such service since it's a glorified copy and paste program! What is your thought? :) – Dave Oct 15 '12 at 08:09
  • 1
    Something very light like MVVM Light would make your life much easier. It sets up all your dependency injection for you and makes the app more manageable. It's got virtually no learning curve (I use it for Windows Store apps) so you can get up and running quickly. Even if you inject the logger directly into the view this would manage this process in a nice, consistent way and provide flexibility. If the app is going to grow then complexity will increase quickly. This will let you control this. – Faster Solutions Oct 15 '12 at 08:12
  • thank you very much, I will check it out; I've been wary of MVVM Light as I wanted to learn the MVVM but may be in this instance it will be OK. Thank you again +1 – Dave Oct 15 '12 at 08:22
1

The Model is something the ViewModel will know about but not the View. If you need to present info about a Logger, you can certainly have a LoggerViewModel that knows about a Logger, and in turn the View winds up getting to know about the ViewModel. There are several ways to do that, and setting the DC in the view constructor is one of them.

After that basic understanding of who knows about who, what really makes the MVVM architecture pattern, IMO, is that ViewModel communicates to the View via databinding. Nothing more and nothing less. Lots of goodies come out of this, but that is the crux of it that makes it different than other separation of concerns patterns (like Presentation Model, MVP, etc)

That said, you need to get a feel for it by working through some sample projects. Asking questions here on SO is fantastic when you get stuck on something, but you must realize your question here is a bit fuzzy at best. Also, unless you are really looking to present logging info in your view, logging is not an MVVM concern. Its interesting alright but not MVVM.

Google Josh Smith's MVVM demo on MSDN for a perfectly meaty yet approachable beginning sort of project. And ask more questions or refine the one here as they come up!

HTH,
Berryl

Berryl
  • 12,471
  • 22
  • 98
  • 182
1

forget the view! at least at the beginning ;)

try to think about what you want and what you need. what i understand is that you wanna handle a logfile. so you need a viewmodel for that.

public class LoggerViewmodel{}

you can put the logfile as a parameter to the vm ctor. now you have to think about what you wanna do with your logfile? for everything you want create a property (LastModified, LastRow, whatever) on your viewmodel.

btw there a two different ways to do mvvm, first is view first and the other is viewmodel first. i do both in my projects and take the appraoch wich fits better (viewmodel first the most time ;)) to my needs.

pls edit your questions and add what you wanna do with your logfile, then we can give you a better answer.

edit:

Can I still implement the MVVM when I don't have a separate Model class?

to answer your question the short way - yes you can. you have to seperate the view and viewmodel and use binding to bind the view to the datacontext(viewmodel).

blindmeis
  • 22,175
  • 7
  • 55
  • 74