Prev: .Net Framework Configuration
Next: Fixed it!
From: -- on 26 May 2010 12:22
I've been out of the .NET game for a few years now [pre 2005] and
starting a little project using the Entity Framework and WPF. My
understanding is that the MVVM pattern is the way to go nowadays, but
I've got a few questions.
This is a purely made up example, so forgive any UI design quirks, and
I'm leaving out a bunch of code just as the INotifyPropertyChanged
stuff.

1. Let's say I've got a heavy-ish model class called Report. I'd like
to create a Report browser type of viewer. I'd like the browser to
have a combobox / listbox / treeview / something where the user can
select the report to view, and a Report User Control that displays the
currently selected report. In all the examples I've seen, the
ReportBrowserViewModel would collection of Reports or ReportViewModels
which is bound to the combobox/listbox/treeview. Something like this:
ReportViewModel
{
ObervableCollection<Report> Reports;

}

The Report User Control's DataContext is a ReportViewModel which is
bound to the current ReportViewModel as set by the
ObservableCollections CurrentItem [I can't figure out how to get this
in code, just in the XAML].

I'd like to not have to bring all the Reports into memory [they're
heavy], so I'd like to just bring in a ReportHeader, which is a subset
of the Report data. In doing so, my ReportBrowserViewModel would look
something like this:
ReportBrowserViewModel
{
ObservableCollection<ReportHeader> ReportHeaders;
ReportViewModel CurrentReport;

}

I'd like the combobox/listbox/treeview to be bound to the
ReportHeaders, and when the ReportHeader's CurrentItem changes, I'd
like to set the CurrentReport to the appropriate Report [in doing so,
updating the bound ReportUserControl]

Is this how it's supposed to be done? If so, this leads to question 2.

2. In the above scenario, the ReportBrowserViewModel would need to get
a Report to fill the ReportViewModel. Is it appropriate for the
ReportBrowserViewModel to access the DAL to get the Report? If not,
how should the Report be obtained?
2a. In general, how is data supposed to be loaded into the ViewModel?
Something has to put the Model objects into the ViewModel. In my
example, should I load the ReportHeader via the Window, or have them
passed in?

3. Commands. Are Model modifying commands supposed to be placed in
the ViewModel? Things like adding a line item to a report? So I'd have
a Command:
AddLineItemToReportCommand : ICommand
{
public AddLineItemToReportCommand(Report report);
....
}

and the ReportViewModel would have a property:
AddLineItemToReportCommand addLineItem;
AddLineItemToReportCommand AddLineItem
{
get{
addLineItem = addLineItem ?? new
AddLineItemToReportCommand(this.Model);
addLineItem = addLineItem.Model == this.Model
? addLineItem
: new
AddLineItemToReportCommand(this.Model);
return addLineItem;
}
}

This would be creating a new Command instance every time the Model in
the ReportViewModel changes? This seems like a lot.

4. A more general generics question. If I have a generic class:
B<T> : INotifyPropertyChanged
{
T item;
T Item{
get{return item;}
set{
if(item==value)return; // Note, this doesn't work
item=value;
OnPropertyChanged("Item");
}
}
}

What's the appropriate method in the setter for checking if the new
value is equal to the old value? == doesn't work unless there's a
class constraint on T, and item.Equals(value) will throw an exception
in item or value are null. My current method is:
if(item == null && value == null)return;
if(item==null || value==null || !item.Equals(value))
{
item=value;...
}
But this seems excessive. There must be a better way.
From: Peter Duniho on 26 May 2010 23:41
-- wrote:
> I've been out of the .NET game for a few years now [pre 2005] and
> [...]

Please do not multi-post. If you feel that your message really must
appear in multiple newsgroups, learn to cross-post properly and send
your message that way.

Thanks,
Pete
From: -- on 27 May 2010 09:51
On May 26, 11:41 pm, Peter Duniho <no.peted.s...(a)no.nwlink.spam.com>
wrote:
> -- wrote:
> > I've been out of the .NET game for a few years now [pre 2005] and
> > [...]
>
> Please do not multi-post.  If you feel that your message really must
> appear in multiple newsgroups, learn to cross-post properly and send
> your message that way.
>
> Thanks,
> Pete

I've never quite understood the stigma of not multi-posting. Multi-
posting and cross posting achieve the exact same effect. I suppose
when disk space / bandwidth was a huge concern it was more efficient
to have to store only one copy of the message, but nowadays I don't
think it's a problem.
Besides, I was hoping to get an answer from one group, and when I
didn't get one, I posted in a different, more active, one.
From: Peter Duniho on 27 May 2010 11:13
-- wrote:
> I've never quite understood the stigma of not multi-posting. Multi-
> posting and cross posting achieve the exact same effect.

No, they don't. When you multi-post, your post winds up treated as a
new post in each newsgroup. Thus, it shows up as unread in each
newsgroup, even if one has already read it.

> I suppose
> when disk space / bandwidth was a huge concern it was more efficient
> to have to store only one copy of the message, but nowadays I don't
> think it's a problem.

It's much more of an etiquette/politeness thing than a bandwidth thing.
If you don't care about etiquette or politeness, then by all means
continue in your current habit.

> Besides, I was hoping to get an answer from one group, and when I
> didn't get one, I posted in a different, more active, one.

Unfortunately, your question is so WPF-specific, the likelihood of
getting any useful answer in either newsgroup is low. Microsoft never
created a WPF-specific newsgroup, but instead pushed everyone to a web
forum.

Even if posted in the correct forum, you may find that the question is
far to elaborate and complex for anyone to want to spend enough time
answering it.

I know enough about WPF to know that I don't like the MVVM paradigm very
much. It seems to me to introduce an extra layer of objects as compared
to traditional MVC for no real benefit. Other than that, I don't have
much to offer to your question, in either newsgroup. (And of course,
because I know so little about WPF, my disinclination regarding the MVVM
paradigm may simply be a matter of being poorly informed as to its virtues).

Pete
From: -- on 27 May 2010 12:55
On May 27, 11:13 am, Peter Duniho <no.peted.s...(a)no.nwlink.spam.com>
wrote:
> -- wrote:
> > I've never quite understood the stigma of not multi-posting.  Multi-
> > posting and cross posting achieve the exact same effect.  
>
> No, they don't.  When you multi-post, your post winds up treated as a
> new post in each newsgroup.  Thus, it shows up as unread in each
> newsgroup, even if one has already read it.
>
> > I suppose
> > when disk space / bandwidth was a huge concern it was more efficient
> > to have to store only one copy of the message, but nowadays I don't
> > think it's a problem.
>
> It's much more of an etiquette/politeness thing than a bandwidth thing.
>   If you don't care about etiquette or politeness, then by all means
> continue in your current habit.
>
> > Besides, I was hoping to get an answer from one group, and when I
> > didn't get one, I posted in a different, more active, one.
>
> Unfortunately, your question is so WPF-specific, the likelihood of
> getting any useful answer in either newsgroup is low.  Microsoft never
> created a WPF-specific newsgroup, but instead pushed everyone to a web
> forum.
>
> Even if posted in the correct forum, you may find that the question is
> far to elaborate and complex for anyone to want to spend enough time
> answering it.
>
> I know enough about WPF to know that I don't like the MVVM paradigm very
> much.  It seems to me to introduce an extra layer of objects as compared
> to traditional MVC for no real benefit.  Other than that, I don't have
> much to offer to your question, in either newsgroup.  (And of course,
> because I know so little about WPF, my disinclination regarding the MVVM
> paradigm may simply be a matter of being poorly informed as to its virtues).
>
> Pete

Thanks, you've been a big help.
 | 
Pages: 1
Prev: .Net Framework Configuration
Next: Fixed it!