I'm writing an application that is supposed to show and hide the content of the main window stack panel based on the user choice. For example, the user clicks on the button that displays the list of the customers, then click on the button that displays the ordering form. The customers content should be hidden and the ordering form should be visible. Moreover, if there are contents with related information (like customers and their data) I want to be able to change the data in one window and it should automatically refresh the data in the other window when the user decides to open it. Is there a good way to do it in MVVM?
Thanks for any suggestions.
Because this question is so generic, the answer must be as well, and the answer is that this is exactly what MVVM is for - modeling data and binding it as needed. In fact, I would argue that a majority of MVVM examples you find online will be some flavor of an answer to your question, most likely using good ol' Northwind.
It sounds like you need to really take a good look at how you want to do your design before you jump in and start coding.
You might want to check out Prism (or as it is really named Composite Application Guidance). You can build really complex and modular designs with it.
You might be interested in the MVVM sample applications of the WPF Application Framework (WAF).
Writer: Shows how the Views (UserControls) can be switched (Edit mode; Print Preview mode).
BookLibrary: Shows how data modified in one View is automatically updated in other Views.
Related
I'm trying to get into WPF and have been reading articles saying MVVM is generally the way to go for WPF.
What about application that doesn't require user interactions such as button clicks?
An example would be a Card reader application:
User connect card.
Application read and display card info on screen.
Perform backend validation.
Display result on screen.
I could be wrong but I don't see MVVM being suitable for such application. Is there a more suitable design pattern that I should be considering instead?
The point of MVVM is to detach your views from your code.
Lets say in a month you need another view, you can easily create one without having to worry about "logic" being part of the view.
Mind you, some things are still easier done in the code behind ... but depending on your "purist" status, it'll vary.
Having said that, you can still happily use MVVM for your card application, and use the GUI to switch around and show different views ...
Last thing is I'll recommend picking an MVVM framework to help you jump start. There's plenty of them out there, varying in complexity and goals.
MvvmLight , Castel (?), Prism, Micro mvvm (?) ... run a quick search and see which you like .
Having said the above, let me shamelessly plug this article: The big mvvm template
I am working on a winforms client server application that will load one of many forms that would be used to enter data or retrieve data or search for data. I want to put buttons on the left side of the screen to select which form is loaded on the right, and buttons at the top for the usual New, Open, delete etc.
I began working on this by making an MDI form that would popup a child window that allows to user to pick the application they want to use. Then when they select it, it would load the appropriate form on the right and update the text and functions of the buttons on the left. I was using panels to load the forms into for the button form (which I called the Navigator) and the application form. I had to use events to make changes to the different button forms when the form on the right was changed. A friend of mine said that I was probably going about this in the wrong way. He said there is probably a better design pattern or methodology or controls that already do that for me.
I dont know how to even search for something like this on the web.
Can someone give me some direction on this?
I can do the research if I am pointed in the right direction.
Maybe there is a control that already does all this?
Thank You.
We use a similar pattern. MDI parent with menus for objects and tasks. MDI Child forms (about 30) for each object/task. Left "nav" button in three groups: 1:1 (calling up l related objects), 1:N (display lists of related objects - inspections, equipment, etc.), N:N:X (other complex relationships or tasks). The body has a tab control to group data. At least one tab is a datagridview that is reused for the 1:N lists.
Left nav button sets are dependent on the object being managed. We add the buttons dynamically but in most case they are hard coded - we just don't use the toolbox to place the buttons on the child forms. Each button set is in a Panel - I would probably use a FlowPanel if I were to start over.
We build a "model" form on one of the more complex objects, built all the data binding logic, and then used that form as a basis for the other objects. We didn't use inheritance as supplied by Visual Studio/VB.Net.
We do our own control data "binding." We use ADO.Net and SQL Server. Our child forms only display one record and do not support the typical record navigation seen in the wizard generated forms - this works fine in our case as we navigate sideways through our data. e.g. Application, Authority to Construct, Permit - then inspections, renewals etc. all related to one Facility. (we're a regulator agency)
We use VB.Net as a lot of the business logic was developed in VB6. I'd still use VB.Net today vs C# - much easier to use for business logic and more maintainable IMO.
One issue to consider - some have out the long knives for WinForms (and VB.Net.) I can't see Microsoft depreciating WinForms but there are those advocating that. Many cannot appreciate the simplicity (albeit limited flexibility) of the WinForms that allows us to concentrate on the business being done. I keep looking at WPF but simply cannot see the usefulness of all the UI power it provides. WPF proponents will push MVVM but that is just more complexity that is not needed for small scale development or production (20 users with desktops o a LAN) environments. WPF does not lead itself to our sideways navigation.
I think the left toolbar for selecting the form is a good pattern, but make it collapsible (hide) so the user could use all the desktop space.
As for MDI personally I don't like it because fell a bit outdated and cluttered. But again look for a balance of form and function.
For the top toolbar I would make it part of each form so it would be easy to program the logic. It an unnecesary complication put them on the master form.
As a recomendation you could look, Designing Web Interfaces even it's more focussed to web could give some pointers in user interaction.
For more informacion search ui patterns, user interaction design.
I'm trying to learn how to design an application which has several different user inferfaces. its an application where a doctor can view patient records, write prescriptions and so on. when designing this one(including the login) I have created seperate user controls for login, prescription writing, medical history browing and set all of their visibility to hidden and then I've put all of them in a single stack panel on the main application window. I'm thinking to display the appropriate usercontrols using the help of code-behind files.
I would like to know is this a valid way of creating wpf applications, or how you would do in desining applications with multiple interfaces (I'm plaining to use some animations on them, such as fade in and hide when closed a user control ).
Thank you.
For a simple project this is perfectly fine.
However as the number of views grow, you might want to design a system for managing this stackpanel.
There is a library designed to handle these kind of situations, you can find it here: http://compositewpf.codeplex.com/ look at the stuff called RegionManager
We were building out the next version of an in-house thick-client application using WPF/Prism (Composite Application Library). As we were nearly done with the client our team was put under new management and shortly thereafter:
We were then directed to drop the Prism framework to keep things simple. This includes not using any type of Inversion of Control.
We were directed to build out the WPF application without using MVVM or similar; and more along the lines of a traditional WinForm application. The idea is that if a developer sees a control in Visual Studio’s designer view, then (s)he should be able to click on the control and see exactly what it's doing without having to traverse through a view-model (or similar).
We have now been tasked with building out the WPF application using one primary Window, use a Frame Control to contain the content, and use a Ribbon outside of the frame for the menu items. Reason we were provided to use Frame Control:
a. We will show a view in the Frame with a Page (not a user control) and then load the page in the Frame.
b. When a new view is to be shown in the Frame, the current view (Page) will be closed/disposed and the new view (Page) will take its place in the Frame.
c. When a developer looks at the Page in design view, (s)he will be able to click on any control and see exactly what is being done.
Given the restrictions of 1 and 2 above, we’d like to present another method of building out the application that:
Can be presented as an alternative to using the “Frame Methodology” (item 3 above) but still provides the same type of functionality.
Does not use MVVM (see #1 and #2 above).
Provided the direction we’ve been given, any suggestions as to an alternative we can present? I’d request that the responses be kept on the professional level and thank you in advance.
I'd personally try to argue to use Martin Fowler's Presentation Model. (That's a joke, btw...)
Basically, you're being given a restriction that says "Use WPF, but don't use any of the features that make WPF usable." It really sounds like your requirements are such that you would be much better off explaining, reasonably, the advantages of patterns like MVVM.
It sounds like the weird requirements are really boiling down to this:
The idea is that if a developer sees a control in Visual Studio’s designer view, then (s)he should be able to click on the control and see exactly what it's doing
If that's the main issue, and the reason you're avoiding MVVM and other similar patterns, I would seriously take the time to educate the management. Looking at a Command, by name, instead of an event, by name (which is what you see in the designer) is really no more difficult.
However, in a large scale application, the separation of concerns is key. Even a properly designed Windows Forms application requires a clean separation of concerns - but with event based programming, this becomes much more difficult, especially from the designer. If you try to develop a large scale, clean, application using an event approach, you'll have event handlers, but those event handlers will all eventually need to delegate their work to a separate component.
This is actually adding an extra level of effort, from an understandability and maintenance point of view, on top of what you get with MVVM. With MVVM, you only look to the ViewModel, which is very discoverable.
BTW - The "rationale" for using a Page instead of a UserControl doesn't make any sense. You can do exactly the same thing you're describing with UserControls... The only reason to use a Frame and Page is if you want to take advantage of navigation, in which case, you can't dispose the old pages directly (or they get regenerated constantly). Also, the navigation tools probably wouldn't be used with a ribbon - the two conceptual models are quite different.
There are criticisms of MVVM which may be applicable to your project; however having unreasonable dictates of programming methodology is always a recipe for disaster.
One of the reasons that we have frameworks and spending time building layers and separation is to avoid the coding mess that always results when you can "simply click on the button in visual studio to see the code that is being executed".
There may not be a way of achieving what you've been asked to do without something similar to MVVM, because anything that has an architecture may well be labelled as being too similar.
However I have been using a system for many years that provides simple inter-object plumbing currently called Emesary you may want to read my C# .NET Emesary walkthrough.
But basically it allows my buttons to be implemented thus:
private void addButton_Click(object sender, RoutedEventArgs e)
{
GlobalTransmitter.NotifyAll(new Notification(NotificationType.CreateRecipe));
}
This may be an answer to your problem. It's under hyped, small and so simple but it just works well.
I've achieved a solution to the second question by using a Window, a user control for the ribbon bar (the user control contains the listview), and another user control for the Frame part. This second user control obvious is built using other user controls using a very simple view class. All views and controls are connected using Emesary.
As a school project I had to develop a WPF client which allowed for multiple people to make use of it at the same time. And I used Pages. My verdict: Save yourself a huge amount of effort, and use UserControls instead.
Sometimes the Page Navigator (which you'll use to scroll through) tends to bug out and cause you a lot of problems. Maybe it was my crappy coding, but who knows?
Though I must say, the control being called "Pages" is somewhat misleading... I went "Eureka!" when I found them, and swore at them thereafter.
I totally agree with #2 (MS bigs take note!). It would be cool if you could double-click a Control and it would take you straight to its command (or event if its command is lacking). However till then, make sure that you organize your Views and ViewModels in separate folders.
Having a dual screen (or a very wide one) will allow you to have two instances of VS open on the project, one focused around the View and the other around the ViewModel (my personal choice was having Expression Blend on the View).
Although not a very big application, I managed to convert my project to proper MVVM (ie. ViewModel for every UI element, RelayCommands and Mediator) in a matter of days, so once you understand it it's not too complicated to implement. Plus, there are tools out there (such as Josh Smith's RelayCommand and Marlon Grech's Mediator - totally free, by the way) which make MVVM half as difficult, and twice as powerful.
Using WPF without MVVM is like trying to eat rice without a fork. You'd be better off using WinForms if you're not going to take advantage of what WPF has to offer. My 2 cents.
I wish I could say your management is totally wrong.. but I cannot say that as it will not be the most accurate truth. I guess that the main reason to the changes you described is either because the new manager is not comfortable with the concept of MVVM being the new messiah of UI development or/and another reason could be the cost of educated sophisticated developers vs. cheap developers which can be instructed to get the things done as fast as possible, a concept which is widely known as lean development.
So, putting all I wrote so far under "not what you asked for", here is what I suggest:
you can still use object oriented pure approach, meaning you can have a model object which already have method to show UI information. so every object will be a window derived object, that way you will loose on SOC but you still going to be OOP/OOD.
But LOL, The next phase will bring you to seperation of model from view in order to not repeat the same code in many derrived windows which relay on the same data... so your management will endorse MVC/MVP as good solution .. and the distance from it to MVVM is kinda of short if they want WPF.
Conclusion: you will have to teach your manager why it is better to go for MVVM, unless the project is very short.
I'm designing data-oriented application in Silverlight 3 and I'm wondering if is it worth using new DataForm control. It looks really awesome on PowerPoint slides but I have no idea how it is in real life.
I need to achieve following behaviours:
group model's fields to areas, for instance separating groups using horizontal lines or naming group of fields,
place 2 or 3 input controls in exactly one row, for example: country-dropdown, zip textbox and city textbox,
multilingual validation errors,
a few readonly fields in edit mode,
posibility to hide fields in dataforms,
displying a helper button for showing modal popup window with dictionary/grid view.
I'd like to build it using Prism and RIA services.
Has anybody any experience to share?
I have tried using the DataForm in a couple of places in my current project. Spent several days tweaking the various properties and attributes on my classes and found that it never did quite work the way I wanted it to. The demos that are on the web look great but they don't have 'real world' scenarios and are incomplete. So, I wouldn't recomend the DataForm for complex scenarios.
My favourite feature of the DataForm control is that it works "out of the box". That is, you can plug one on your user interface, bind it to your data classes, and have it working with a minimal amount of code. Of course you need to further tune both the behavior and the appearance of the form (by using attributes on the data classes and/or properties on the form control itself), but for feasibility studies or for early usage testing it is usually enough (and very useful) to have it working quickly with the default behavior.
By the way this is a good resource to get started with the DataForm: http://www.silverlightshow.net/items/Creating-Rich-Data-Forms-in-Silverlight-3-Introduction.aspx