Developing new C# .net4.5 Windows Forms application. I want to code it "right". I'm developing a couple User Controls. The controls are shared via several tabs. On the controls are some common drop down boxes that are populated with the same SQL Server table data. (one or two columns) I want to read the DB once and have the lookup data available during the entire user experience. The app will be used by many users. Whats the best way to store this data in my new code? example code appreciated. cache? static list ? Help! Thanks!
Simply a global DataTable (Dataset) would do. Or if you want control over the contents of the list using SortedDictionary containing your own custom class for each row would suffice.
The Custom Class is a tidy way of holding a cache (for the data you want from each row), as you can override the ToString function and populate the user controls easily.
To share this cache amongst many users is not easy, and could prove more trouble than its worth. Each user with a separate copy of the program would have their own copy of the cache (in the 2 methods above). (But the user controls will also contains subsets of this cache too). And each program would need to load the user controls, so perhaps this sharing across multiple instances direction is moot.
Related
Are there any solutions out there for sorting with data virtualization? The use case is a large set
of transactions sorted in any of several ways. Editing a transaction puts it out of order, saving it may move the transaction to a different page. By itself that is not so bad, however (a) it has to work with a validation system and (b) other entries can be added or edited prior to the save, resulting in an increasingly disordered list.
One solution that I think wouldn't work very well would be to resort each dirty page (e.g. right after the save)I because that would significantly increase the number of entries notified to the list view, resulting in flicker.
I don't follow your question. Maybe, you want to sort your collection on your ItemsControl. There should be some third-party controls can achieve your target.
For example, DataGrid in Syncfusion.
The SfDataGrid control for Universal Windows Platform is used to display collection of data in rows and columns. It includes editing and data shaping features (Sorting, grouping, filtering and etc) that allows the end users to easily manage the data.
What I did in the end was to only use a single virtual page. With just one page you can more easily manage the relocation of edited entries, since you won't have to move them between pages or deal with them falling in between pages. New entities can be kept at the bottom of the collection until they are saved. Having only one page also improves the chances of detecting concurrency errors.
Note this question was not primarily about re-sorting, it was more about maintaining a sort order during edits.
The DataGrid suggestion does not suit the situation, I need free-form templates rather than a grid.
Validation, concurrency, and the need for batch edits just make it a bit harder.
I found the different are:
Data Store:
- Property-Value pair
- No random data
Data Source
- Property-Value pair under Collection
- Random data
Does these 2 feature is helper to create XAML?
What different between them and what's the aims of usage?
Thanks you.
The DataSource is used for sample data. You can use sample data to have some data to work with when designing your application. In the end you will replace the sample data with real data when running the app. More on sample data here.
A DataStore is used in combination with Behaviors, Data behaviors to be more specific. Sometimes you need to store a property to make a design work, a simple counter for example that triggers a change in design when a certain limit is reached. You could add this to your ViewModel and bind it to your view, but sometimes it will just clutter the ViewModel.
I'm not sure if I stated my question clearly, but I have two seperate pages and a single view model. Originally I only had one page, but I decided to split these up because my pages were getting too large (more specifically I had too many pivot items on a single page where two pages would seperate the data better for the user). I was wondering if it was possible to only load specific data to a single view from the view model, because as it is right now my application is freezing because my view model attempts to load all the data even though only about half of it needs to be used on the current page the user is viewing. If so, I'm assuming I would somehow need to let the view model know which data to load. How would I accomplish this. OR, is it good practice to create two seperate view models, one for each page, so that only the necessary data for each page will load accordingly and keep my application from freezing? I am not sure what the standard is here, or what is the most efficient in terms of CPU usage and response times, etc.
Loading more data than you need can definitely be a problem especially if you're doing it over the Internet. Why do it like that? Why not simply separate the viewmodel in two parts? The definition of VM basically says: (quote from Model-View-ViewModel (MVVM) Explained)
The viewmodel is a key piece of the triad because it introduces Presentation Separation, or the concept of keeping the nuances of the view separate from the model. Instead of making the model aware of the user's view of a date, so that it converts the date to the display format, the model simply holds the data, the view simply holds the formatted date, and the controller acts as the liaison between the two.
If you separated the view, you might as well separate the VM too in order to keep things simple.
Still, if that doesn't do it for you and your data is not exposed as a service of some kind, why not just using the parts of VM? Call only the methods you need according to the page which you're seeing, set only the properties you need, don't do it all. And do it on a different thread if the data is really large to process so that your UI doesn't freeze (and of course, in the meantime show the user that you're getting the data using a progress bar).
That should be enough for the scenario you described.
The home page of meetup shows information on the recent meetups on the right hand side of the page. What kind of design patterns / tools (pref java based) would you use to implement such an output.
There's a couple of different approaches, which one you use would depend on several factors including the complexity of the business processes, the degree of flexibility desired and load.
Simple Solution
"RSVP Updates" are written directly to some data source during the "RSVP" process; this process is essentially hard-coded.
Have something that reads out the RSVP directly from the whatever data source / table they live in.
This solution will be fine if the load and data volumes are excessive. The key point is that the RSVP UI widget ends up pulling the data out of the same data source as where the updates are written to.
Performance
A few different options, based on the above as a starting point:
Hold the data twice: once in the "master" (Transactional) table of RSVP data, and once in a table built for servicing the UI (Basically OLTP vs OLAP). The second table would include all the relevant data so that there were no look-ups to other tables, and as it's an independent copy of the data you can manage it differently if you want to (for example: purge out old records so the table size is kept small).
Or, instead of a second table just keep all the data in memory. this would require you to pull the data out of the main transactional table whenever the in memory copy is lost.
Flexibility
Same as the original approach but instead of hard-coding in the step that records the RSVP (into a single data source) use a more loosely-coupled approach so that you can add / change / remove as many event processors as you wish. One will write the RSVP data to the main RSVP data source, while a second will do the same/similar but aggregated ready for the
"Recent RSVPs" UI Widget.
Dependency Injection will give you the flexibility - certainly if you deal with a single implementation of the event handler.
The Publish / Subscribe or Chain of Responsibility patterns might give you the basis of an approach.
Is that the kind of info you were after?
I'm working on a new Joomla! module where I need to store a read-only data of about 40 key/value pairs with a keyword and corresponding URL link. There are several options but I'm not sure which one would be convenient for the programmer and fast-loading for the user. Or maybe because the data amount is so small it doesn't really matter what method is used.
I could hardcode the values into an array as part of the module code. Not convenient to update but it does load fast.
I could store the data in an flat file or XML file. This would require additional code to implement and would be convenient for updating the list, but doesn't load as fast as being hardcoded.
I could create a table in the database. The Joomla API makes this is a no brainer to use but I'm not sure how much overhead there would with everything else being loaded from the database.
How do I logically evaluate which one works best without trying out each of the options?
Your two opposing concerns are
frequency with which the programmer updates these key value pairs
frequency with which the application queries them
If they're updated more than occasionally, your best bet is to have them in the database and then cache the data at some desirable interval if you're worried about it.