Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
What is the ideal way to organize the code for form controls when using WinForms? This sounds ambiguous, let me expand to add clarity.
My application uses a number of form controls. ListView is one of them. Before the app launches I have to set the headers of the ListView, andd the columns, grab the data, populate the ListView etc. Not only that there is also the code to redraw the list view when items are removed or adding, and also various code for events on the ListView.
This is one example. My application uses a number of controls that have a lot of functionality and require setting up prior to loading or redrawing at run time.
To stuff all this into the main Form would just get complex and messy.
What are ideal options for keeping things clean, tidy and maintainable?
If you were looking for element ordering rather than a design pattern then I suggest Style Cop. After you get used to it, it makes finding the code you want much easier. (Style Cop has many other rules regarding commenting etc, which also make code organisation much easier).
According to style cop element ordering rules http://www.stylecop.com/docs/SA1201.html elements should be placed in the following order:
Extern Alias Directives
Using Directives
Namespaces
Delegates
Enums
Interfaces
Structs
Classes
Within a class, struct, or interface, elements must be positioned in the following order:
Fields
Constructors
Finalizers (Destructors)
Delegates
Events
Enums
Interfaces
Properties
Indexers
Methods
Structs
Classes
Edit
Since the OP's last edit I see this is not really what he's talking about.
I'd recommend moving all code not directly related to user interface into another class, or multiple classes and only keep the code that directly references UI controls in the Form class.
You can use design patterns such as:
Model–view–presenter (MVP);
Model-View-ViewModel (MVVM);
Model–view–controller (MVC).
They are great for separating the logic layer from the user interface layer. You can see some examples here. This one is for Model-View-ViewModel (MVVM) and works for me.
The good thing about design patterns is that they make your code testable.
There are a lot of patterns that you may use to modularize your code. A popular way of populating your GUI with data is using an MVC or MVP paradigms. If you need to get your data without blocking your UI thread then you can use delegates in your Presenter/Controllerto retrieve necessary data from your underlying datasource(s).
Create a constructor for the form controls ,and handle the functionality from the constructor. Or hanlde the functionality in form_load event of the form that contains the control
Related
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 4 years ago.
Improve this question
I am in the process of learning ReactiveUI and so far I love it but I now realise that the framework encompasses XAML (i.e. the view layer) as well, offering things like ReactiveUserControl and ReactiveView.
Why do I need, or want these? System.Reactive/ReactiveUI offer massive advantages on the Model/ViewModel side but what are the advantages on the View side, again, in the context of a WPF app? Unit testing perhaps?
Note: I like WPF, I like its data binding. All my XAML bindings are strongly-typed and easy to refactor, customise, re-skin, debug and whatnot. I learned to use but not over-use the converters so never have a prob with those either. I never felt a need to override the UserControl class. With that said, I never had a problem with the WPF itself.
If I decide to use the IVIewFor<T> implementations, will my XAML designer go nuts? Will I lose anything? Will I end up debugging memory leaks, UI stutter and strange CPU spikes? We'll be making a very large app so we go by the 'better safe than sorry' principle as we were burnt by the CAB framework before.
If I decide against, what benefits of the ReactiveUI will we lose? Would I be heathens for doing this, or is it more of an optional aspect of the framework?
So far I understand the benefits in case of WinForms or Android (it offers binding support as I understood) but not WPF. While it sure does have its quirks, I don't feel the need for another framework on top of it.
You would implement IViewFor<T> when you for example want to set up bindings in the view and when you want to handle activation and deactivation, e.g.:
this.WhenAnyValue(x => x.ViewModel.Name).BindTo(this, view => view.Name.Text);
this.WhenActivated(d => { /* do something */});
These methods are implemented as extension methods. Please refer to the docs for more information and examples:
https://reactiveui.net/docs/handbook/data-binding/
https://reactiveui.net/docs/handbook/when-activated/
Of course you don't have to use all features of ReactiveUI. It's perfectly fine to set up bindings in the XAML markup as usual and still bind to ReactiveObjects.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 5 years ago.
Improve this question
I have tried many options for a long time and that is the last one that comes to my mind, so I will try to ask:
I am trying to develop an MVVM project in WPF and I have downloaded a ready-to-use WPF control (GMap.NET). However, this control is not prepared to use it in MVVM and I am a newbie in that, so I do not want to modify a source code on my own. The control requires to set many parameters (not accessible through XAML, so I cannot simply bind them), and call some functions on control object. So here goes my question:
How can I access a WPF control instance from any place from the code and manage it from there?
Particularly, I want to access a View element from ViewModel part and I know that it brakes the pattern, but I have no idea how to avoid it and I am running out of time.
Hard to say without knowing the concrete control. But in general, I see 2 options for make such a control MVVM conform:
Subclass the control and add dependency properties so it can be used in XAML
Create a "container control" that wraps the unMVVMable control and provides the required dependency properties.
However, if the API of the control is complex and has not only properties, but also some methods, it may be pragmatic do break MVVM here. MVVM is not the only way to separate GUI related logic from the view. You could abstract the used functions with an interface and use the interface within your view model for example.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
SITUATION
I am working on a (MVVM, Composite) WPF application, where everything should to be done in a very loosely coupled way.
When it comes to applying styles, I already have a nice little solution:
Each and every control, that is used, lives in an separate DLL, no matter if needs special styling or not.
In the constructor, each and every control, calls a static method, which delivers the right style for this control.
Example for a TextBlock:
public partial class TextBlock : System.Windows.Controls.TextBlock
{
public TextBlock()
{
InitializeComponent();
//The class ResourceCreator knows, which style to deliver
this.Style = (System.Windows.Style)ResourceCreator.FindResourceByName(
Styles.StyleNames.TextBlock);
}
}
This program design is okay so far because you never have to apply styles anywhere. The class ResourceCreator knows which style to apply to this control and of course it can switch between different styles. The control itself doesn't know, which style will be applied.
WHAT I WANT
In an MVVM application, a rule of thumb is, that there should be no logic at all in the code-behind of the View. Everything happens in the view model.
I want to break this rule only to apply styles. Any window or view should have one method in the code-behind, that iterates over the visual tree. Each detected control-type should be identified and then the appropriate style should be applied.
QUESTION
Is this a bad or good idea? Are there any facts, that I don't see, which are against this idea?
In an MVVM application, a rule of thumb is, that there should be no logic at all in the code-behind of the View. Everything happens in the view model.
You are wrong. MVVM is not about eliminating code from the views. It is about separation of concerns. It is perfectly fine to write any view-related code in the code-behind of the view.
And styles are purely view-related. So is any code that controls or interacts with the view layer that is difficult or inefficient to express in XAML, such as for example complex animations. These kind of things should not be implemented in the view model.
So you are not breaking any MVVM rules here :)
Your application logic should be implemented in the view model and your business logic should be implemented in the model. But any pure view-based functionality should be implemented in the view.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 6 years ago.
Improve this question
I'm going to develop a C# windows application which hosts several tabs in one form. Since components inside each tab are complicated enough, having all codes stored in one file Form1.cs is make it hard to handle all methods and code snippets.
I want to know are there any good practices to manage code in such condition?
I have made Forms Applications like that before, and I know what you mean about the code getting cumbersome for the .cs file.
Assuming you're not doing this already:
What I would do is compartmentalize some of the methods and members to separate classes that you call when needed via access operators and/or references. If you find yourself reusing the same set of lines dozens of times, put it in a static method that you can call everywhere without having to declare class objects... Each Tab can call some kind of method like RunTab1(); that will access the appropriate objects, classes, members and so forth. This way, when you want to work on Tab2, you can go to that class and ruffle through there, instead of going through one GIANT file looking for one small thing.
I know that sounds like a bit of a generic answer, but I've done it and it worked for me for a multilingual translator among many other things. Even what I'm working on now - some of the files are over 30k lines and I don't get any lag at runtime. Hope that helps.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 9 years ago.
Improve this question
So I'm having trobule figuring out the best way to use the MVVM pattern while creating a WPF control dynamically within
my code. Would this even make sense or is it better to avoid the MVVM pattern all together?
If it does make sense then please share code examples of the view model.
In general, if you're using MVVM, controls will only be created "dynamically" in response to the data changing. If you have an ItemsControl bound to a collection, for example, the controls to represent the items will automatically be created for you.
If you're talking about making a custom control in general, custom controls are really "pure view", so MVVM doens't really make sense in this scenario. The main goal of creating a custom control is to build it in a way so that it can be used by code developed with MVVM, which typically means building the control with proper Dependency Properties (so data binding works properly), etc.