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.
Related
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.
What would be the application development process for WPF applications and silverlight application?
Like how many tiers the application is divided into and how they communicate with each other. And what steps are followed during development like design , then business logic layer.
How the data base is accessed can Linq be used or data sets are better option?
I would suggest that you start out using the WPF Application Framework. Your "tiers" should be something along the lines of:
Business "Model" logic (database, LinqToSQL/EntityFramework is great with WPF)
Your "View" which is your WPF/Silverlight controls
Your "ViewModel" which binds the Logic to your View, passing change notifications anduser interactions.
I would do these steps in order. Assuming step 1 is mostly complete since it's not really unique to WPF/Silverlight, make an interesting UI but don't tie it to your model quite yet. Then study up on ViewModels. ViewModels, strictly bound and not accessed in code behind, will give you the best results.
If you're already familiar with C#/.NET, I would also strongly suggest you check out this excellent screencast showing you how to retrofit an application to following the "Model, View, ViewModel" architecture.
The process would be the same as for any other application; that is, design an architecture to suit your requirements! However, within your actual WPF/Silverlight code, you might want to look at the Model-View-Viewmodel architecture.
MVVM is a pattern that is typically used to structure the code behind a WPF UI, though it doesn't dictate how you access your data or define your business logic. The MVVM code would sit on top of your business/data code and provide an abstraction that's suitable for the UI to work with.
This question isn't really about WPF or Silverlight as they are just UIs. The architecture isn't dictated by whether you use Silverlight, WPF or something else.
For example (and not limited to this scenario), if you are using a classic n-tier architecture, you could continue to do so while using a Silverlight front end.
I come from mainly a web development background (ASP.NET, ASP.NET MVC, XHTML, CSS etc) but have been tasked with creating/designing a Silverlight application. The application is utilising Bing Maps control for Silverlight, this will be contained in a user control and will be the 'main' screen in the system.
There will be numerous other user controls on the form that will be used to choose/filter/sort/order the data on the map. I think of it like Visual Studio: the Bing Maps will be like the code editor window and the other controls will be like Solutions Explorer, Find Results etc. (although a lot less of them!)
I have read up and I'm comfortable with the data side (RIA-Services) of the application. I've (kinda) got my head around databinding and using a view model to present data and keep the code behind file lite.
What I do need some help on is UI design/navigation framework, specifically 2 aspects:
How do I best implement a fluid design so that the various user controls which filter the map data can be resized/pinned/unpinned (for example, like the Solution Explorer in VS)? I made a test using a Grid with a GridSplitter control, is this the best way? Would it be best to create a Grid/Gridsplitter with Navigation Frames inside the grid to load the content?
Since I have multiple user controls that basically use the same set of data, should I set the dataContext at the highest possible level (e.g. if using a grid with multiple frames, at the Grid level?).
Any help, tips, links etc. will be very much appreciated!
Microsoft has created a great community site for helping people get started with both design and Silverlight here: http://www.microsoft.com/design/toolbox/
It may be far more than what you need for your current project, but it definitely will give you the training you need to master Design with Silverlight.
I am new to WPF application and are developing a new WPF application which does 4 different things (4 different modules).
I was googling around and found regarding WPF composite application.
I was reading through the msdn articles but and a few a different place but all the apps are very large and so understanding them is a bit difficult.
Has anyone got a very simple WPF composite application or any link where i can find it out?
Your question is very broad, but I'll try to give you a few tips.
This is just my $0.02USD since I've reacently approached a similar challenge.
First thing, don't approach this as a WPF composite application, think of it as a composite application that you wish to reflect onto a WPF window. There's a big difference. Each module of your composite should be a self contained, and fully functional unit -- later you can tie some of the functionality to WPF controls. If you try to design this from the ground up to work with and only with a certain WPF interface, you're entering a world of pain with difficult refactoring and untestability.
Research the Model-View-ViemModel (MVVM) approach to WPF application design. For each of your modules create a ViewModel -- which is an adapter class that exposes the functionality of your module ("Model" in MVVM) to a WPF control ("View" in MVVM).
I would suggest you do something like the following:
Design independent classes for each
of your 4 modules.
Create 4 Visual Studio "Test
Projects" that test each method of
your modules.
Create 4 ViewModels that instantiate
a single reference to your modules
and exposes their functionality,
even if these ViewModels seems
redundant at first.
Create 4 WPF UserControls that
instantiate your ViewModels.
Research WPF data binding and have your UserControls access your modules through and only through their respective ViewModels.
Each of these steps are very broad and will take lots of work, but there are plenty around here that will help you each step of the way once you get into the specifics :D
Good luck!
WPF/Silverlight - Prism - Resources for beginners
I started developing a small app using WPF and PRISM. The msdn article helped me and the have look at the above stackoverflow question..
I am kind of new to the whole MVVM pattern, and am trying to wrap my head around it. What I am currently trying to figure out is: in a well structured solution where do the ViewModels live?
Currently my design looks something like this (sort of):
Application (The view)
DomainSpecificCode (ClassLibrary)
Gateways (ClassLibrary)
If I were to add on another type of view (for instance ASP.NET or Silverlight), where would be the best place for the ViewModels to exist?
ViewModels should go in the Application layer because they tend to be technology-specific.
For example you may want to databind a View attribute to a particular color based on the state of the ViewModel. However, Color is implemented by different types on Windows Forms, ASP.NET and WPF, so you wouldn't be able to reuse the ViewModel accross different technologies.
If you add new Applications, you must also provide new ViewModels.
Recently, I built a MVVM Desktop application that had 2 flavors:
WPF Document Base GUI
Console application
Both exe were using the same view models, one was WPF and the other one was not.
I was able to split my solution into the following projects (libraries/exe):
non-project related re-usable code (called Common)
project models + persistence
project view models
WPF application + views
Console application
It was amazingly easy to build the console application version just by using the View Models. The console application code had less than 200 lines of code, and was basically loading the ProjectViewModel and doing operations on it.
This article describes a concrete Architecture for WPF MVVM Applications.
Layers:
Presentation Layer: Views
Application Layer: ViewModels
Domain Layer: Domain specific code