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.
Related
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.
This is a new project we are doing using Spring MVC 2.5, jsp , Java7, Ajax, and HTML5. On my part I am going to have have 7-10 jsp pages which contain one form each.These pages are sequential. i.e One have to pass the first page successfuly to go to the second and pass the second page to go to the third and so on.
The data in order to be persisted, one has to get to the last page (after passing the rest successfully) and confirm the information is correct. Once the user confirms, I have to persist all the data stored in a bean or session (All or none). No incomplete data should be persisted. Let's call our database table "employee"
I am new to Spring MVC but got the idea and implemented the page flow using a controller.
My question is should I need to have one model class or bean to store all the data, or use session to store each pages information and keep it in the session until it gets persisted?
Or its better to have one model class, but multiple controller/bean to control the data flow from each page. Which one do you recommend? Is there any design pattern already implemented to answer my question? If you have a better idea please feel free to discuss your idea.
There are two approaches as you have already mentioned. Which one to use depends on the datasize and other requirements, for example, whether the user can come back later and continue from where he left. The model and controller need not be just one. It can be designed appropriately.
a) Store data from each screen in the session:
Pros: Unnecessary data is not persisted to db. Can manipulate data from within the session when user traverses back and forth on the screens and hence faster.
Cons of this approach: Too much information in the session can cause memory issues. May not be very helpful during session failover.The user cannot log back in and continue from where the user left, if this functionality is required.
b) Persist each screen data as the user moves on:
Pros: Session is lighter, so only minimum relevant information is stored in the session. User can log back in and continue from where the user left.
A separate inprogress db tables can be used to store this information and only on final submit insert/update the data into the actual tables, else the db would contain a lot of unsubmitted data. This way the inprogress db can be cleaned up periodically.
Cons: Need to make db calls to persist and retrieve for every screen, even though it may not be submitted by the user.
You are correct about your use of the HTTP session for storing the state of the forms.
or use session to store each pages information and keep it in the
session until it gets persisted?
because of this requirement:
No incomplete data should be persisted
As for
should I need to have one model class or bean to store all the data
You can model this as you see fit. Perhaps a model to represent the flow and then an object for each page. Depends on how the data is split across the pages.
Although as noted in a comment above you might be able to make use of WebFlow to achieve this. However that is ultimately just a lightweight framework over Spring MVC.
I am collecting some data from a user. The data is complex, consisting of up to 40 (as few as 18) fields of data. The path of data entry is also complex and will have multiple sub-paths. I am accomplishing this using partial views, Ajax, and view models. The page never refreshes. This process involves a lot of dynamic content being placed on the page, and a series of evolving view models which contain more and more data as the path is followed. I am going to end up with around 20 partial views and 20 view models.
Is there a more standardized way of doing this while still avoiding a page refresh (such as not using so many view models)?
No, there is not a standardized way of dynamically doing this.
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?
How closely does your data model map to your UI and domain model?
The data model can be quite close to the domain model if it has, for example, a Customer table, an Employee table etc.
The UI might not reflect the data model so closely though - for example, there may be multiple forms, all feeding in bits-and-pieces of Customer data along with other miscellaneous bits of data. In this case, one could you have separate tables to hold the data from each form. As required the data can then combined at a future point... Alternatively one could insert the form data directly into a Customer table, so that the data model does not correlate well to the UI.
What has proven to work better for you?
I find it cleaner to map your domain model to the real world problem you are trying to solve.
You can then create viewmodels which act as a bucket of all the data required by your view.
as stated, your UI can change frequently, but this does not usually change the particular domain problem you are tackling...
information can be found on this pattern here:
http://blogs.msdn.com/dphill/archive/2009/01/31/the-viewmodel-pattern.aspx
UI can change according to many needs, so it's generally better to keep data in a domain model, abstracted away from any one UI.
If I have a RESTful service layer, what they are exposing the domain model. In that case , the UI(any particular screen) calls a number of these services and from the domain models collected composes the screen. In this scenario although domain models bubble all the way up to UI the UI layer skims out the necessary data to build its particular screen. There are also some interesting questions on SO about on using domain model(annotated) for persistence.
My point here is the domain models can be a single source of truth. It can do the work of carrying data , encapsulating logic fairly well. I have worked on projects which had a lot of boilerplate code translating each domain model to DTO, VO , DO and what-have-yous. A lot of that looked quite unnecessary and more due to habit in most cases.