Alright, so I'm creating a WPF application using the MVVM design principles anad C# as the language.
I have a singleton for my database (called 'Database'), which just loads some data from an XML file.
I also have a view model (ScenesViewModel) which needs to get this data once it's loaded.
At the moment, the Database calls its Load method in MainWindow.Xaml.cs (just below InitializeComponent) and the constructor of ScenesViewModel gets the data from the Database singleton.
The problem is that the constructor for ScenesViewModel happens before the singleton does its loading.
I suppose I could have a reference to ScenesViewModel in the Database singleton, but that seems like bad practise to me. Is there a better way?
I am, as you may be able to tell, no expert in this field.
Thanks in advance.
Load data from Database async and use await keyword waiting until data loads from database. Go to reference:
https://msdn.microsoft.com/en-us/library/mt674882.aspx
Related
So, I don't know if the question is explicit enough, but here's my problem:
I am writing a small application in VB.Net, that retrieves information from a website and present it to the user. Basically, I have written a class, which has a Get(URL) method which retrieves the webpage, reads it and populates the various Properties (Read-only) of the object.
This class works OK.
Now, I would like to store that information in a Database (I'm using Access for now), so that I can read the data from the DB, if the class gets called for a known URL. As I'm fairly new to OOP and completely new to DB usage in desktop applications (no problems in designing the DB though), I am not sure on how to proceed:
Should I put the database code in my existing class?
Should I create an extended class based on the existing one, adding the DB code?
Should I create a completely different class for the DB data and put the switch logic (read from DB or from web) in my application?
...
I realize that my question may sound silly to the most experienced of you, but I'm new to this and I would really like to learn how to do things the right way the first time!!!
Thanks!
This is what I would do:
Create a new class for the database code, and create an
interface for it that it implements.
Then create another class that has the code to fetch the web data. Make it implement the same interface.
Now you can subsitute either class to do your data access from your controller class.
Also, I usually put database and data access in separate projects from my service and ui classes, which are in their own classes, but that might be overkill for your situation.
If you'd like to read more on the subject, look up n-tier application design. The tier you're talking about here is data access.
http://en.wikipedia.org/wiki/Data_access_layer
I have zero experience with Backbone.js currently, and before I start having a good look, I wonder if anybody could advise if it is a good fit for my use case.
I have a dashboard where I will present multiple real-time graphs, with the data source being provided a socket.io.
I would like to use the same data source on multiple pages of the dashboard.
Would backbones's models be a good fit here i.e. setup a model that uses the socket.io data source, and then makes it available to all views?
Basically whenever socket.on is called, i need an object in each of the views to be updated.
Is this possible?
Any thoughts would be much appreciated.
Best regards, Ben.
Yeah, that's possible. There's a library for Backbone that replaces the Backbone.sync method with an implementation that works over Socket.IO:
https://github.com/logicalparadox/backbone.iobind
I have a WPF DataGrid for which data comes from a stored procedure. I want to know how can I virtualize that data?. I am using ADO.NET Entity Framework. My data in the database changes regularly and it needs to be fetched regularly through my stored procedure. Thanks in Advance.
Try to have a look at this post in order to see if it is useful to you. It is a generic solution to virtualize a collection. There is a sample too. Basically it works by proxing the data inside the collection to intercept when the UI observe the element, when it occours, a page is fetched. The only drawback is that the entity in the collection as to be declared as "proxable", so it must be public and with virtual properties.
I have a class running in a winforms app which uses EF Code First. The DbContext is created via DI through the class constructor. All works well.
The problem is the data being referenced is also being modified via a web site, using the same DI pattern with EF Code First, and the data changes are not being reflected in the context instance in the winforms app.
I can solve this by recreating the DbContext object in winforms every time I access it, but seems to be more of a service location pattern to me?
Is there a true DI technique to achieve this?
Or should I remove the context from the DI and use service location?
Were you not happy with the answer to your other question (http://stackoverflow.com/questions/7657643/how-to-force-ef-code-first-to-query-the-database) which suggested using Detach, AsNoTracking or Overwrite Changes?
1) Maybe you could pass an interface that has the ability to create a DbContext, instead of the context itself.
using(var context = _contextFactory.Create()) {
var entity = from table in context.Blah...;
}
The Create method could either create the concrete class itself (defeating the DI pattern a bit), or use service location to have one created for it. Not that nice, but it's better than embedding service location calls everywhere and still means you're controlling the lifecycle yourself.
2) Change the WinForm to read from a webservice run by the website, effectively similar to disabling caching.
3) Deep in the heart of MVC (well not really that deep) it is referencing the DI container directly and using it as a service locator to pass as arguments for newly created objects. Technically you could do something similar in WinForms, but it would need you to split your application up into little chunks (controllers) that don't have a very long lifetime. Maybe it's worth looking at some MVC/MVP frameworks for WinForms, although I found myself cringing at most I saw after a quick google.
The problem is the data being referenced is also being modified via a web site, using the same DI pattern with EF Code First, and the data changes are not being reflected in the context instance in the winforms app.
This is a problem with your expectations.
If your web service and window forms app are in separate processes, they won't share in-memory data.
If you want to sync their in-memory data, simply re-query in one context after committing to the database in the other. This is the same as trying to share data between different SQL connections.
I can solve this by recreating the DbContext object in winforms every time I access it, but seems to be more of a service location pattern to me?
If you want to recreate the DbContext repeatedly, you could use an abstract factory to allow manual re-creation of the object, yet allow you to inject the specific implementation into the factory.
This is not (necessarily) the Service Locator pattern, and you would have to ensure that you manually dispose your DbContext instances. I'd give you some example code, but different DI containers have totally different ways of accomplishing a factory pattern.
Or you could simply make sure that you commit your data on the web service side, and re-query the data on the WinForms app side.
I'm learning about MVVM and one of the things I don't get is how the model and the view model are supposed to communicate. I also don't understand whether they are separate classes, composite classes, or whether the ModelView is supposed to inherit from the model.
I need to get some data from a web service, so I think the model should be responsible with it and make the appropriate web service calls. But since these requests really originate in the view as a result of the user wanting to see some information it means the ModelView has to forward that request to the model somehow, then provide an asynchronous notification mechanism so that the view isn't stuck while the model asynchronously retrieves the data. To summarize, suppose we have the following use case:
View: ComboBox --> bound to List in ModelView. Model view is connected to Model in (?????) way. The data that will populate the list can be retrieved by a web service call. How does this scenario work?
Let's make your scenario a bit more complicated: user clicks a button and then a list needs to be populated with a data that comes from a web service.
In this scenario:
View's list is bound to ObservableCollection in ViewModel.
View's button is bound to a command in ViewModel.
ViewModel's command's handler will fire an asynchronous request to a web service and subscribe a listener that will handle a response.
The response handler will populate the observable collection with the items from the response once it's received. Since View is bound to the ObservableCollection it will automagically update its list on the screen.
Now whether you encapsulate a web service call in an another class (e.g. Model) or leave it in ViewModel highly depends on your own preferences (e.g. having it in a model allows to to easily test ViewModel by injecting a mock rather than having a web service running, etc.)
In short, the view model is fully aware of the model and can interact with it directly. Don't overthink the interaction between them. The only double-blind relationship is that between the view and the view model.
I think it is worth mentioning that you do not always need three different classes for your MVVM "combos". The V will always be its own class, the VM will probably also need its own class (I don't think it has to, though), but the M can be the same across the entire project if that suits your application. If you are building a small application, let's say you only have 10-15 different service methods in total, it will probably make sense to have one single class responsible for calling your web service, handling errors and making the asynch callbacks to the various VMs. And if you are building a really small app, maybe it will make sense to have only one VM and, say, 2-3 Views that bind to that single VM. Maybe in that case you don't even need a separate Model class at all, just call the web service directly from your VM. After all, you will have created a service reference to that web service. The generated proxy classes will then act as your Model.
What I am trying to point out is that when reading about MVVM it is easy to assume that there will always be three physical files for each MVVM "combo". That is what I thought when I started experimenting with MVVM, and I thought to myself "Wow, that's a lot of files. And Wow, what if I have some common methods in the web service that need to be called by multiple Model classes, then I will have tons of duplicated code all over the place.". But when my head cleared I realized that it's up to me to decide what works best in my app.