views:

57

answers:

1

I have a UserControl with some custom dependency properties bound to a clr property in the ViewModel. The ViewModel has application logic where I deal with the TextPointer/TextRange classes with a FlowDocument.

Should I put that stuff into the code-behind of the UserControl or in the ViewModel?

ranges.Clear();
            TextRange range = new TextRange(boundXamlDocument.ContentStart, boundXamlDocument.ContentEnd);
            foreach (var block in boundXamlDocument.Blocks)
            {
                if (block is Paragraph)
                {
                    Paragraph p = block as Paragraph;
                    //if paragraph has Strikethrough, then do not loop its inlines.
                    if (p.TextDecorations.Contains(TextDecorations.Strikethrough[0]))
                    {
                        TextRange tr = new TextRange(p.ContentStart, p.ContentEnd);
                        ranges.Add(tr);
                    }
                    else
                    {
                        foreach (var run in p.Inlines)
                        {
                            if (run.TextDecorations.Contains(TextDecorations.Strikethrough[0]))
                            {
                                TextRange tr = new TextRange(run.ContentStart, run.ContentEnd);
                                ranges.Add(tr);
                            }
                        }
                    }
                }
            }
A: 

I only bother to design custom/user controls when I have a concept that won't fit well into any of the usual controls (rare to never), or I have custom control behavior that I want to reuse (more common).

The more abstract your control can be, the more reusable it will be. Although, making it so abstract that no one would get any benefit from it would be doing too much :)

If you have application logic, it is best to define it in the view model (or model) when at all possible. When that logic changes, it won't break other users of your control.

If a feature of the control isn't specific to the exact presentation/user input style, and is specific to that instance of the control, you should probably put it in the view model.

Edit:

From your comments, it seems that the code you are trying to write depends on UI elements (TextBlock text decorators). This means it must and should go in the view.

Merlyn Morgan-Graham
well judging from your answer it seems code-behind is always a no-go...I have updated my init post with a sample code how it could look like... should I really put that into my ViewModel where I also declare my private IDocumentRepository _documentRepo = new DocumentRepository();_documentRepo.DoStuff(); That looks really strange put the application logic and Repository stuff together in one class seems like the presentation layer and data access borders are blurring...
Bluna
@Bluna: I don't know about *always* being the wrong thing to do. Code behind == View. If it is view specific, it is okay to put it in code behind, as long as it isn't to much work/too confusing to put into the XAML.
Merlyn Morgan-Graham
ah your post was 4 secs ago when I added my sample code :PI can not put this code into xaml as it would not work...
Bluna
@Bluna: I like to think of the view as throw-away code. If you wanted to present another view at any given point in time, what code would you want to keep around? It seems that you'd always want this `if not strikethrough` code, no matter what the view, so it should go in the view model.
Merlyn Morgan-Graham
with sample code I meant this is not my code just a sample... ;-)I think the worse a control is implemented regarding DepProp the harder MVVM is to implement.TextDecorations on a Selected Text can only be retrieved via textblock.TextDecorations and I do not think I pollute my ViewModel with UI Elements like textblock...
Bluna
@Bluna: Yeah, definitely no UI elements in a view model. Since this is view specific, put it in code behind.
Merlyn Morgan-Graham