The project I'm working on is a single page web application developed using MVVM as design pattern.
Aside the first request for the entire page every other transaction is JSON-based, every JSON is binded using Knockout at presentation level.
At the moment we're developing the whole application using a single Knockout-viewModel, every single JSON is being parsed inside the viewModel and binded to the presentation level.
Now, considering how big is the viewModel at the moment I'm wondering if it's a good practice to split the whole thing in different (smaller) viewModels specifically binded to a single element in a page (like it's described in this article), making heavy use of the mapping plugin of Knockout to generate the empty structure (and refresh the datas).
In case this isn't the best practice, how do you suggest to manage the JSON binding? At the moment we're using $.jsonparse() to obtain an object then we push the different datas inside some observable array. But I don't think this is the best way to approach this problem.
Thank you.
I'm a big fan of fanning out complexity across lots of smaller modules, rather than a single monolithic module with all the complexity.
I tend to have multiple view models and communicate between them using the Knockout.Postbox library.
Related
Okay so I have around 20k records and 29 columns of text-only data that i fetch from a back-end into an Angular app.
once I get the data from the server (takes around 1s) I bind it to a field in a component and then use an HTML table combined with *ngFor to display all the data.
Chrome takes about 58 seconds to render everything in one go and scripting time is around 10s.
it is a big requirement for my company to be able to see results in the page in under 2.5s from the moment I click on the link to the component without using pagination or infinite scrolling.
what are my options to achieve such performance?
It's hard to tell with limited knowledge about the app and model but I see 2 options (you can go for one or both):
lazy load paginated table content. I don't know which (if any) UI framework you're using but you can check how it's handled in NgPrime for instance Lazy table
EDIT: It can be realized in few ways:
First: if backend is problem (not in this case) you can request only slice of data from backend and handle it with some library like NgPrime
Second: if you're not using any framework you can use something like virtual scroll Virtual scroll
slim down model which is sent over the backend. If large collection of objects has some nested objects as props it can significantly slow down both download and rendering. Instead of having nested object you can decide whether you really need all data which is trasferred and make some light object instead.
Also check out dev tools and analyse loading performance to get more info:
Find bottlenecks in chrome dev tools
EDIT:
With more data provided from comments, I would use virtual-scroll or similar mechanism (it loads and renders html dynamically).
Let's say I have a bunch of kittens. Perhaps I have a KittenViewModel. I want to show it as a kitten card in a card view, but also as broken down into columns in a list view. Does MvvmCross support binding the KittenViewModel to multiple views? Should I have multiple ViewModels that refer back to a single model?
Disclaimer: I know that I am replying to an old question which you may well have forgotten; this is for posterity. Also, I have limited understanding of the MVVM design pattern. I remember reading somewhere that Views and ViewModels are typically in 1-to-1 correspondence, so the conventional answer is probably "You shouldn't do that. Reconsider your design."
With that being said, I recently struggled with this for a while before coming up with a very simple solution that operates under the following assumptions: (1) you wish to use the exact same instance of a ViewModel in two separate Views; (2) for whatever reason, you cannot use a DataTemplateSelector to determine which View to use; and (3) you do not mind creating multiple Views for the same ViewModel.
The solution is to define separate data templates for the KittenViewModel as resources for whatever controls you are going to use to display the data. For example, if you have created a KittenCardView user control and intend to display it in a ContentControl, you can set the DataTemplate in a ContentControl resource, something like:
<ContentControl>
<Control.Resources>
<DataTemplate DataType="{x:Type viewmodel:KittenViewModel}">
<view:KittenCardView/>
</DataTemplate>
</Control.Resources>
</ContentControl>
The KittenColumnView (or whatever you call it) would be handled similarly. You may find it helpful to define one of the Views as a Window or App resource if typically use one and only need the other in special circumstances.
Continuing to work on my port of a CakePHP 1.3 app to 3.0, and have run into another issue. I have a number of areas where functionality varies based on certain settings, and I have previously used a modular component approach. For example, Leagues can have round-robin, ladder or tournament scheduling. This impacts on the scheduling algorithm itself, such that there are different settings required to configure each type, but also dictates the way standings are rendered, ties are broken, etc. (This is just one of 10 areas where I have something similar, though not all of these suffer from the problem below.)
My solution to this in the past was to create a LeagueComponent with a base implementation, and then extend that class as LeagueRoundRobinComponent, LeagueLadderComponent and LeagueTournamentComponent. When controllers need to do anything algorithm-specific, they check the schedule_type field in the leagues table, create the appropriate component, and call functions in it. This still works just fine.
I mentioned that this also affects views. The old solution for this was to pass the league component object from the controller to the view via $this->set. The view can then query it for various functionality. This is admittedly a bit kludgy, but the obvious alternative seems to be extracting all the info the view might require and setting it all individually, which doesn't seem to me to be a lot better. If there's a better option, I'm open to it, but I'm not overly concerned about this at the moment.
The problem I've encountered is when tables need to get some of that component info. The issue at hand is when I am saving my add/edit form and need to deal with the custom settings. In order to be as flexible as possible for the future, I don't have all of these possible setting fields represented in the database, but rather serialize them into a single "custom" column. (Reading this all works quite nicely with a custom constructor and getters.) I had previously done this by loading the component from the beforeSave function in the League model, calling the function that returns the list of schedule-specific settings, extracting those values and serializing them. But with the changes to component access in 3.0, it seems I can no longer create the component in my new beforeMarshal function.
I suppose the controller could "pass" the component to the table by setting it as a property, but that feels like a major kludge, and there must be a better way. It doesn't seem like extending the table class is a good solution, because that would horribly complicate associations. I don't think that custom types are the solution, as I don't see how they'd access a component either. I'm leaning towards passing just the list of fields from the controller to the model, that's more of a "configuration" method. Speaking of configuration, I suppose it could all just go into the central Configure data store, but that's always felt to me like somewhere that you only put "small" data. I'm wondering if there's a better design pattern I could follow that would let the table continue to take care of these implementation details on its own without the controller needing to get involved; if at some point I decide to change from the serialized method to adding all of the possible columns, it would be nice to have those changes restricted to the table class.
Oh, and keep in mind that this list of custom settings is needed in both a view and the table, so whatever solution is proposed will ideally provide a way for both of them to access it, rather than requiring duplication of code.
It seems that both can represent a view, that is if you request a servlet it will show you an html page, and so the same if you request a jsp file, just the way they are implemented are different.
Now I know that servlet are more than, that. They control requests and so on, but still after reading so many days, still don't know how to use them in harmony together.
If i need some logic, do I put it in a servlet, and then what? How do I present my data, from the servlet or from a jsp file located in the same folder?
In other words, do I even need jsp files when I use servlet, and if yeas why???
It seems that both can represent a view, ...
JSP was introduced because it's much easier to invoke Java to render parts that are dynamic in an otherwise static HTML template rather than trying to print out the whole page in Java through servlets (too many println(), escaping quotes etc. it's a mess). So, JSP is better suited for rendering views.
MVC is all about separation of concerns: request handling and routing, business logic and application data, and the views with all the presentation logic.
JSPs later enhanced with EL (Expression Language), JSTL (Java Standard Tag Lbrary) and other such tag libraries that encapsulate the presentation logic are better suited to support the View layer.
Model represents your application data and all the business rules that you apply on them. They're implemented as POJOs (plain old Java objects i.e. not extending or implementing platform specific classes or interfaces) .
Servlets and Filters with their request dispatching capabilities and inherently existing in the Java environment are better suited as Controllers to interact with the Application Server, the Model and the View. They facilitate all the routing and the flow of data between the three layers.
If i need some logic, do I put it in a servlet, and then what?
Your business logic neither goes in Servlets nor JSPs. That goes into your business classes (POJOs) insulated as much as possible from the type of application platform (which is J2EE here).
A simple request to demonstrate its use would be to ask you to port your application into .Net. A-ha! Suddenly, writing all that business logic inside your Servlets/JSPs, that cannot be easily reused now, doesn't feel like such a good idea.
So, ideally, your servlets would intercept the client requests and invoke some business class to fulfill it. This may return some data (like results from a SQL query) wrapped as a domain data object (also referred to as data value or data transfer objects).
How do I present my data, from the servlet or from a jsp file located in the same folder?
Before redirecting to an appropriate View, the Controller servlet would push the domain object into some scope (could be request, session or application depending on the requirements) or a sophisticated data store available with an MVC framework (like the ValueStack in Struts 2).
The View, which is your JSP, would then pull the domain object from one of these scopes or ValueStack and render its required properties for display through EL with JSTL tags or OGNL expressions with tag libraries provided by the MVC framework.
It is of good style to separate logic from presentation. (1) You can easily change the logic not touching the presentation and vice versa. (2) You can use a right tool for each task. Pure Java in servlet's code is good for implementing logic. Templating engine, including JSP, is good for presentation, where your work is largely in HTML with some points where you're inserting data from the application.
You can read about Spring as an example how to use JSP in the best way.
Is it legal In MVC, so that a "model" make use of "services" to load some data ( from web) so that the data after loading can be passed into a list box of a "view" ?
My focus is on "Can Model make use of Services directly for such purposes?"
V.
I agree with Anshu's answer but I'm personally flexible about this kind of thing on my own projects if I plan them to be very small scale, that is it doesn't seem to always be worth the time to create the clear MVC separation. There's also MVVM based on MVC, some decent info on that on wikipedia and you can find it elsewhere http://en.wikipedia.org/wiki/Model_View_ViewModel
There's no set in stone rules when it comes to design pattern usage, but if you set your own rules and work within them (particularly adhering to MVC in one or more layers of abstraction) can be helpful particularly on large projects or where a team is involved.
So the answer to your question about a model making use of services is yes this is possible, is it conforming to a strict MVC pattern, no.
The model should simply be the structure that holds the data in whatever way the data relates to other data, that's what the model is made up of. The controller handles the dirty work of making the calls to the service and updating the model. The view simply is bound to or updated when changes to the model occur and makes use of the controller (usually in as3 by using event handlers on ui components) to make the right updates to the model (or calls to then update the model).
You'll likely have extra helper classes that may sort of fit somewhere in between or outside of the parts that make up the model the view or the controller, this is okay but you should be conscious of what purpose these serve and document them well and make sure it wouldn't make sense for them to somehow be handled more elegantly within the whole setup.
I would say, its rather the responsibility of the Controller to make use of services and populate the model with the data obtained from services.
This link should provide more clarity about the responsibilities of Model, View and controller in Actionscript-3