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
Some 30 years ago, I developed a big app for fresh fruit packers. I followed a nice paradigm, taken from Informix-4GL: the same screen allows the user to set a "query by example" or to insert a new "record", or update one of them after a successfully one. It maintained a "current list" (the resulting query result and the new records added) wich could be navegated with PgUp and PgDwn Keys. Of course, all that stuff was expressed as mapped text.
The very important thing is that the screen was idle until the user did a "command" to start a new query, an insert or update (or even a delete) operation.
Now, it's the time to evolve that app.
I'm thinking in Wpf and its Preview* group of routed events, to catch the main user "command".
But because there are lots of screens (near one for every entity in the database) it's important to set what is common between them.
Is it the best way (in Wpf) to set one or two "super classes" of Windows for this approach?
TIA
Technically — sure, you can create a class that inherits from System.Windows.Window, have all windows in your app inherit from that one, and implement some common logic in that class.
However, this approach is not considered a best practice for WPF and other XAML-based platforms. Your window and other GUI classes should only contain code specific to presentation. Your model classes that handle the DB queries should not depend on the exact GUI you’re using to present these models.
While not required, a third-party MVVM library is helpful to e.g. provide design-time models for the IDE. As for the specific library, lately I prefer Caliburn Micro, before that I had positive experience with MVVM Light.
With MVVM, it’s fine to have a base model class with some logic that’s common across different model classes. In fact, many libraries encourage you to do so. They provide their own base classes for your models. Such as Screen or PropertyChangedBase from Caliburn Micro.
Related
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 3 years ago.
Improve this question
I am making my first attempt at applying the MVVM pattern and have made it to the point in my application where I need to bind the data to the UI. A couple of articles that I have read mentioned breaking the final visible data down into the most common datatypes possible (eg. int, string, bool). I currently have some data grids bound to ObservableCollection objects and I am struggling to find where the line on "Common enough" data types are.
Should I look into breaking my objects down into more simple data types or would it not be worth the effort?
One of the reasons for choosing to use a MVVM pattern in this project is because we may want to switch to Xamarin in the future for mobile UIs.
Please note that I (currently) only have experience with WPF.
Should I look into breaking my objects down into more simple data types or would it not be worth the effort?
No. Keep the Models based on the database or webservice call and keep them at that.
I would only distill them down, if there is a specific need, such as extrapolating a property between multiple properties.
Keep in mind that MVVM is not a religion, its a fancier way of providing a separation of concerns from the view, the data and the database/Service. It used to be called "3-tiered architecture" back in the day.
grids bound to ObservableCollection objects
Binding will work with just plain lists. One only has to use ObservableCollections if items are dynamically being added or removed from that collection. Then a notification is sent to inform a control that binds to that collection to update from the changed collection.
But if the collection will not change for the lifetime scope of the operation, keep it a plain generic List.
I provide a basic example of MVVM and databinding (without ObeservableCollections) which might help your understanding:
Xaml: ViewModel Main Page Instantiation and Loading Strategy for Easier Binding
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 6 years ago.
Improve this question
I'm writing an application in WPF and found myself loving whole MVVM paradigm. My only concern at the moment is that my ViewModels are becoming heavy. They contain Commands, logic to enable and disable buttons, instances of other ViewModels, async method with DispatchTimer timers etc. Is this something that is normal in this kind of development environment? Or is there some logical way of organizing ViewModels without becoming too "crowded"?
Keep in mind that the ViewModel is just an adapter between your model, where logic and data live, and the view which is shown to the user.
The idea is you can easily swap views or change them, without the logic suffering from that.
Having said that, depending on the complexity of your application, they might grow quite big, but if it's mainly stuff that ends up enabling/disabling stuff on your view, and isn't doing logic / processing stuff, I'd say this is where it's supposed to live.
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 am short on time,and I need to develop a desktop app that will be used in a firm.
I dont have time to learn mvvm or any other design pattern.
Can I develop an app without it?
I did some basic sql crud with a table and it works fine,but I wanted to ask you if I can develop a whole app without some of this design patterns.
EDIT: You can do it,but you have to be carefull,also there will be more effort included if you want to edit some things down the line.
You don't need to rely on MVVM when using wpf. Really the keys to
using wpf properly are:
-Use commands instead of events (you might do this without realizing
it, but check to make sure)
-Use data binding instead of getting values
off of controls directly
-Set the data context and bind to that instead
of binding to the code behind
MVVM works really well for these two
things but is not required. Specifically, MVVM requires a 3-tier
strict separation of concerns that can just as easily be done with
MVP.
Source :
Developing WPF software without MVVM
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 8 years ago.
Improve this question
For my company, I have developed one winform application, that handles Unified COmmunication.
It's been 1 year in development. I Just write global functions in seperate classes, and write the code in either form or class. Now They wanted me to make three seperate copies(UI of each changed) of the same Software. I have changed all UI and everything needed, and made 3 copies. But now, I feel it very difficult to correct any issues, or add any features. I have to change it in my all three copies. How can I solve this. Thanks.
I'll assume the three versions are very similar. First off, it's of the utmost importance that you keep your project under source control.
Personally, I would have created a dev branch for the main version, and then create two other branches for the 2 other versions (e.g., dev-v1 and dev-v2), created off the main branch.
Then, whenever I had to apply a patch to all 3 versions, I'd do it on the dev branch, and then merge dev with dev-v1 and again with dev-v2.
So far I only addressed the source control issue, but as CSharpie pointed out in the comments, you should definitely separate the presentation layer (i.e., forms) from the business logic. Furthermore, these two should also be separated from the data layer.
Take a look at Multitier architecture.
Separation doesn't necessarily mean different projects or solutions. Having a logical separation (e.g., having sets of classes with very well defined purposes, following the SOLID principles etc.) is often enough. In your case, however, it seems that the presentation layer should be in a different project than the other two.
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
This might be a bit vague, but I am working on a program where several classes that update the UI. I have made a "middle-man" class that basically takes all the UI requests (among other things) and routes them to the UI itself, that way the UI class only interacts with the middle-man.
The problem is that the UI class has ~20 different functions in its interface, and all my middle-man class does is basically take calls from the lower-level classes and then call an essentially identical function in the UI, which makes me wonder if this is somehow defeating the whole purpose. I'm sure this is a problem that comes up a lot. Is there any more elegant way to do this?
Thanks,
PM
It's nice to not have to refer to UI stuff in the backend. I assume this is the reason you're wanting to do this.
If that's the case, what you could do is implement some Publish/subscribe pattern (such as the Observer pattern). That way, you don't have to refer specifically to the UI. You can just "publish" from your backend, and subscribe to those events from your UI.
Alternatively, you could inherit your UI from an interface, and specify the methods you need on that. Then, refer only to the interface in your backend.
Unfortunately you don't really state what you are using to build your UI. But the whole problem can quickly disappear with WPF (or Silverlight) and data binding. In a nutshell items in the UI are bound to properties and commands in a backing class. When a property changes the PropertyChanged event is raised and the UI knows to update itself. For more information start searching on MVVM.
At the end of the day, this is actually a form of the observer pattern, but you don't have to do all the wiring yourself.