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.
Related
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 1 year ago.
Improve this question
I got some businesslogic I want to handle inside of a .cs file.
Depending on the outcome of that, I want to update the blazor UI, EG a toast notification or a variable change. How could I do that?
Thank you in advance.
This is not easy to answer as your question is not specific, and we don't know how proficient you are in programming. However, the following answer may illustrate the path you should take in the context of Blazor:
Your class should be defined as a service, which you should add to the DI container from the Startup class, and injected into your relevant components.
This service class, generally speaking, should implement two patterns: The State pattern and the Notifier pattern. The service is supposed to hold some state, as for instance, a given value passed to the service from component A, which trigger an event handler that propagate this fact to other subscribing components, passing them the new value passed from component A via EventArgs or properties. The complicity of the service depends on the functionality you want to expose.
Search Google for strings like "enet stackoverflow Blazor notifier", and such like to see relevant code provided in my answers.
See these links:
https://stackoverflow.com/a/62042629/6152891
https://stackoverflow.com/a/66370816/6152891
You need to use ComponentBase.StateHasChanged in response to whatever is happening in your business logic. Since you didn't post any code it's hard to be more specific but that method will force the relevant component to re-render.
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 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
Ok, this subject is probably done to death but I wanted to throw it out there to see what people thought of my approach.
I need to create a simple WinForms application that will consist of a handle of forms. There will be variables that I can stick into the app.config as they'll never really change. However there will be some variables that are pulled in from a database unique to the user thats logging in. It's these variables that I need to persist and make available to the rest of the application to drive appropriate business logic.
Based on other articles on StackOverflow my plan would be to use the singleton pattern with IoC. So first instantiating a class based on the singleton pattern which is hooked up to an interface. The instantiated object would then be passed into the constructer of other methods in program.cs where I'll arrange most of my objects. This should mean I can easily test and mock this and other classes (I think?).
I've seen there are two ways of creating a class based on the singleton pattern, one that is the 'classic' way of doing it but isn't thread safe. The other requires slightly more coding but would be thread safe. My WinForms project would be pretty simplistic and wouldn't require multiple operations running in the background. Just simple CRUD operations fired off from the UI. For ease, I thought I'd use the classic singleton (non-thread safe) approach. That said, is that a bad thing to do, even for the most simplest of WinForm apps?
If you're using .NET 4.0+, just use Lazy<T> class for your singletons. If you insist on not caring about thread safety (why though?), get => _value ?? (_value = GetValue()) is enough.
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.
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.