I have wandered into a WPF application project and have made some good progress, but one thing I am finding is that the code-behind page is now getting longer and longer... since there is only one XAML page to the whole application, the code-behind page that really just takes care of the event handlers and programmatically created controls for the design page, is now over 2000 lines. The VS2010 IDE helps in navigating all the methods, etc, but I am wondering if I am missing something as far as organizing all my controls and code-behind. Is there a way to break out some of the UI of the application into multiple XAML pages, so the code-behind will be more compartmentalized to a specific set of controls. Any search I do on multiple XAML file applications in WPF immediately leads me to XBAPS and I am interested in staying with the desktop WPF. Aside from creating regions in the one code-behind, are there any other strategies I can use to organize this code (in separate XAML files)?
Thanks!
At a minimum, separate out parts of your UI into separate UserControls, instead of including it in a single "view" in a single Window.
That being said, separating our your logic and using a pattern like MVVM will make this much cleaner in the long run. It sounds like you're using lots of event handlers - I wrote a blog series designed to help migrate from this style of development to a more MVVM style. It might be worth glancing at for ideas. It describes how WPF allows you to move away from having lots of event handlers by keeping your application logic separated from your UI code.
Related
I am building a rather large WP7 application and having a lot of fun with it. It is Pivot based and has quite a lot of pivot pages. I dynamically add and remove pivot pages based on what "mode" of the application the user has selected to keep the application look and feel as simple as possible. All is going quite well so far my app is fast responsive, not a memory or resource hog and performs background loading on demand when needed.
The Model layer contains all my business logic that represents what the application is all about. It is clean and separate from the the view-model and view layers.
The View-Model layer is an abstraction of the model to the extent that it needs to interact with the view and also contains the session-ness and workflow aspects of the application in general. It contains objects which represent the Model in a way the View needs to interact with. The view model persists the state of the application in isolated storage and supports tomb-stoning.
The View layer contains a lot of elements pivots, user controls, styles, resources etc in both xaml and the corresponding code behind. I do like Blend and the Xaml designer within visual studio 2010 however I find myself still coding/configuring the view objects within the code behind due to the nature in which they interact with each other. The code behind of the view objects is becoming quite large but still only reflects the state of the view and not the state of the application. I have made use of user controls quite a lot as this lets me build reusable components across many pivot pages however the user controls are not Blend friendly. What I am worried about is that my view might becoming more complex than it needs to be and losing the ability to coordinate the user interface design with tools like expression blend.
By customising the view this way and making use of reusable controls I have reduced my Xaml considerably and don't suffer from bloated Xaml files that other developers have mentioned but lost ability to co-ordinate with Blend. Is there are happy medium to be found? Should I be looking at designing custom controls?
[Edit]
Thanks for your reply. I think it boils down to either a lot of Xaml with a designer or break it down into user controls with more code behind. Since I moved into user controls my mindset has moved back to doing things by hand rather than with a designer (better the devil you know right!). My thoughts are should I make my user controls into skin-able custom controls or just keep going how I am and avoid using the designer. Its a bit of potato-potardo but I don't want to get into bad habits.
Custom Controls (or Templated Controls) are not directly related to your question as far as I can see. Custom controls are just controls that add new properties, events and methods to an existing control and are still capable of being 'templated' by a designer.
Creating UI in code does make it harder to design the application using Blend (and even the VS designer) because the only way to see the interface is by running the application.
A lot of the logic that creates the UI could possibly be replaced by using the Visual State Manager. Use states of the controls to design them for specific modes of the view. Only when you need extra/new states you will have to create a Custom Control.
As your question is a bit wide, feel free to add comments or extend your question so I can add more details or remove this answer when it is utter nonsense :)
I am starting on a silverlight application and my MainPage is getting to be fairly large. I am not sure how to properly make a silverlight app in terms of object orientation or separating things into multiple xaml pages. Is it normal to have all of your application in the MainPage? For large elements such as a drawing tool, do people make custom controls and then add them in the main page?
I'm not really sure how to set this up and was hoping someone would shed some light on what the normal architecture of a silverlight app is.
As Steve B suggested you should look into MVVM and use that basic pattern to separate your application into views, models and view-models which bridge the gap between the view and the underlying models. The pattern is not difficult and works very well for data binding in WPF and SilverLight.
To manage the complexity of your main page use multiple UserControls to keep different parts of the UI in different files.
I understand MVVM's usefulness in the context of a large team developing a shrink-wrapped application over a long period of time. But in the context of an internal LOB application, MVVM seems overkill and I'm having trouble swallowing the overhead of debugging declaritive databindings, jumping from layer to layer to layer, and extracting VM's that are barely more than the Model with a command or two. Even accepting that overhead, still leaves me with the holes in MVVM like dialogs. A few things I've considered is:
Binding directly to the Model and do old-school event handlers for form interaction
Binding a user control or window to itself, effectively using the code behind as the VM.
Include a property in my VM to reference the related view.
Make ViewModel's subclasses of a View.
The above items and their combinations address some problems but not all. I do realize that I might sacrifice testability. What other technical (not conceptual like SOC) issues will I run into using one or more of these practices?
I always use MVVM when coding in WPF or Silverlight, even for small single-page apps. It makes it much easier to test and maintain in the long run, and I find it faster to create apps with it than without it
I don't mind taking some shortcuts in smaller apps, such as binding to the Model instead of exposing the Model's properties in the ViewModel, or defining my View in a DataTemplate instead of a UserControl, or using Window's Dialogs in my ViewModels, but I would never consider doing a WPF or Silverlight app without MVVM.
If you want, I have an example of a very simple app done with MVVM here
Code re-usability comes to mind. Properly written VM's could be re-used behind Silverlight or WP7 implementations down the road.
I am very new to WPF, about 4 hours new. I am coming from ASP.net and Masterpages.
I was looking at examples of Control Template that can used to template a window so all windows look the same.
Other post
Can some direct me to an example of how it is accomplished or sample code from start to finish?
Second part:
Is the ControlTemplate the best way to go about building WPF windows client applications? What is best practices in architecting WPF windows applications.
Thanks
There really isn't a "best" way to architect WPF UIs. It all depends on the user experience your application will have.
If you want a very web-like experience you are probably better of using the pages constructs. Otherwise if you have windows, but want a common header, you may just want to make a control template for that. Maybe you need separate windows or maybe you just need to have a sub part of a grid panel change content depending on state... There are different ways to do things that are more or less suited to the type of client experience you want.
Although there are some best practices in relation to using MVC/MVVM design patterns, there isn't a "best" way to style and theme your controls. I don't consider WPF as friendly to newcomers as WinForms were, but at the same time it seems a lot more powerful in the long run. What might help you out are some basic levels of theming:
Styles: these are mainly aesthetic changes to the look and feel of basic controls and elements with some very basic support for triggering things like mouse cursor roll over. They are similar to CSS on webpages.
Control Templates: these are the more heavyweight versions of styles where you actually reconstitute a control so that, say a button can have a textbox inside of it. Where styles work on a logical level where something like a button is the most atomic element, control templates can drill down further into controls so that the border, background, text, etc of a button are seen as separate elements instead of one atomic part.
Data Templates: A more focused version of control templates meant to customize how data items in lists are drawn. If you have a bunch of pictures you don't want the file name to show up in the listbox, you'd rather have the image itself. A data template lets you accomplish this kind of thing.
So you have to ask yourself when you say, "Make all windows look the same," do you mean changes are merely aesthetic/looks (styles), customizing how a collection of items are displayed (data/item templates) or altogether changing how a standard control looks and behaves or making sure the layout of controls on a page are the same across multiple windows/pages (control templates)?
Finally, the "end to end" of the other post you linked to is pretty simple. You take the control template there, and under your tag you simply add Template={StaticResource MyTemplateName} and the template is applied. This article on MSDN is a decent intro to control templating.
I'm having real difficulties with XAML files in Silverlight since they get very big very fast when using Blend. It just becomes a wall of text after only a handful of controls are added and animated.
I'm hoping a better vesion of Blend will come out soon, so that our designers will never even have to see XAML. For now, though, that is not a solution - XAML still needs to be managed manually and it is a depressing task.
Has anyone found a solution to this? How do you keep your XAML files in order? How do you understand them when they get big?
Edit: I am especially interested in Silverlight solutions, since the most obvious WPF solution - splitting things up into resource dictionaries - is not supported in Silverlight.
It does require a little bit of work to maintain XAML files, but basically, what you need to do is split them up in resource files (XAML Resource Dictionaries) using a scheme that makes sense to you.
For example we use a scheme where we have a folder structure like this:
Resources (contains XAML Files that represent the user controls and pages)
Stencils (XAML files with Shapes)
Styles ( XAML Files with styles)
Brushes ( ... )
Shared
Templates ( ... )
Your structure might vary but, separating all resources in different files really makes maintenance more easy in the long run.
I have been using Silverlight 2 since January when it was in private release, and we ran into this problem, all our XAML was in one big file. What we did as best practices was to break up the user interface into separate user controls based on visual categorization (header, footer, navigation controls etc..) Originally we tried to use nested canvases (grids had not been added to the framework yet) and this turned into a maintenance nightmare later.
In Blend you can actually select a Canvas/grid etc... from the Objects and Timeline window, right click on it, and you are given the option "Make Control.." This made for speedy re factoring and modularizing our main XAML file. We then used Events to allow the user controls to communicate between each other.
Hope this helps, and good luck!
I'm a Creative Developer and work in Blend extensively.
I published a few thoughts last year on keeping XAML clean.
Silverlight currently does not support MergedResourceDictionaries so it's hard to break out the XAML into separate ResourceDictionary files as I suggested in another post.
Paul Stovell also has some interesting guidelines for XAML.