I have a MVC 2 web application that will have a high volume of users. One page in particular will be rendered based on XML from a database table. I was hoping to use de-serialization to parse the XML into an object tree for easier access to the data. However I'm not so sure that this will perform well enough for my users. Is there any other methods to parse the XML that will have better performance implications? I'm not that familiar with XSLT but is that a viable option?
Thanks in advance!!
We decided to go with the xslt transformation. Problem solved.
Related
I have a requirement in which i get two json file in request and I need to copare two json files.
Is there a way within ODM where can show customers the UI for text comparision of json ?
Lets say, json 1 file has a field name which is different from json2 name. I need to show with any report /Ui that this is the difference between two files.
Any help would be appreciated.
Thanks in advance
The ODM user interfaces, either Eclipse-base Rule Designer or web-based Decision Center, allow extensive customization, but these UI's are for authoring the rules, not applying them to input data.
ODM rules are generally run within a server environment, so at execution time there is no user or user interface. It is possible (and feasible and reasonable) to embed ODM execution into any Java program (for example, one with a UI to show or compare differences between JSON document), but ODM does not provide any kind of UI framework for building such a program.
I faced the same problem and used JsonAssert library to compare Jsons in Java.
Best
Emmanuel
I have created Web API.I know the Main advantage of Web API is cross domain application (I can call Web API in all platform). My question is ,Is there any performance issue When I call Web API in ASP.net WebForm???
I would like to know the below scenario
1.I Can use Direct SQL Query in .aspx Page
2.I Can use Web API and generate JSON to DataTable
I would like to know which one is fast and better to use.......
I have tried in JQuery,the performance is fine but I would like to call in ASP.net WEb Form
Where you call the API from or from what type of app makes no difference. Your issues are going to come from how you use it and what you do with the results of the calls.
Yes, you can get JSON data from the API and yes you can convert that to a DataTable, technically no issue there, but the performance will depend on how much data you retrieve in one go and how many transformations you go through to get it to the state you need for your webforms controls.
You're talking about using a dead tech ( webforms ) and trying to fit some things into how that works, which while possible, is not really the way to build anything these days.
SQL in aspx kinda says it all.Assuming you have an old app, that you just do updates to then just do what you can, but I would start looking into modern ways of building web apps. You don't have to keep using webforms controls anymore.
You can't talk about scalability when you still have stuff thrown in aspx pages. You need to start thinking about a proper separation of concerns, think about testing your stuff, retrieving only the data you need etc etc. Just because you add WebApi in the mix, that doesn't mean you'll get all the benefits, if everything else does not catch up to the required standard.
There is no inherent performance issue with using WebAPI, aside from the overhead of an additional network hop.
In real world terms, I think this would be negligible and outweighed by the benefits:
You get the 'cross platform' benefit you mentioned.
Better scalability as your 'service' and 'web' concerns are seperated and can be scaled appropriate to the load they need to serve.
The service layer functionality is re-useable, for example if you wanted to develop an app later.
Considering the most popular MVC/MVVM client-side patterns (like Knockout.js, Angular.js, Ember.js, and others), I have one great doubt:
Also considering the modeling redundance in both sides, what is the advantages and disvantages to use those client-side patterns with MVC server-side patterns?
I struggled with how to answer this question... hopefully this helps, even if it is in a round-about way.
While some of the pros/cons have already been stated, I think the best rundown is in this answer.
For me, the biggest advantage to using client-side logic is the rich UI aspect.
But the key part of your question seems to be "model redundancy" (I'd call it duplicated logic, or at least having potential for duplicated logic). In my opinion, that is a problem which may exist independently of the pros/cons in the previous link.
So first of all, I think that the decision of whether or not to use a client-side framework should be made based on the well-documented pros and cons. Once that decision is made, the associated problems can be solved.
Lets assume you are using some sort of server-side framework/platform, as well as a client-side framework to provide a little bit of UI interactivity. Now there is a problem with where to put the model logic: on the client, server, or both.
One way to solve the problem is to define your model logic in only the client or the server. Then you have no code duplication, but it affects some of the higher-level pros/cons.
For example, if your model logic is 100% server-side, you lose some of the interactive part of the UI. Or, you are constantly throwing the model to/from the server, which will have a few cons.
If your model logic is 100% client-side, you could suffer performance problems, depending on the size of your view / model. This is one of the reasons Twitter is moving to a server-side processing model.
Then there is "both"... having model logic exist in both the client and the server. I think this is the best solution, as long as no logic is duplicated.
For example, on a shopping cart page, you may recalculate the cost of an order based on the price of a product, and a user-editable quantity box. I think this logic should only exist on the client. Other model properties that do not change once loaded are probably fine hosted on the server.
There's a lot of gray area here... I struggle with putting all the eggs in one basket. For example, choosing a client-side framework, creating a lot of client-side logic, and then [hypothetically] running into problems with performance, browser support, or something like that. Now you may want to tweak a page or two for performance (like move it server-side, a la Twitter). But I think being smart about how you structure your code will help mitigate that issue. If your code is maintainable and clean, moving logic from client to server won't be difficult.
The advantage is that the client side patterns are applicable at the client where the server has no direct reach. If you're building a rich, interactive HTML UI then use client side MVVM. Server side MVC may still be relevant in that case for delivering appropriate content to the client. For example, the ASP.NET WebAPI is a framework for creating HTTP APIs which has a similar controller architecture to the ASP.NET MVC framework. The API implemented with this framework may be called by client side code resulting in MVC on the server side and MVVM on the client side. Normally, when using MVC server side and MVVM client side, the responsibilities of the respective sides are very different and thus there is no redundancy.
The fact you an incorporate a MVVM model into an already implemented MVC framework is also a great thing, we recently added knockout to some new project pages to fit with in an already outdated MVC framework (old pages, not the framework itself).
I think MVVM is fantastic as the above answer states it provides an exceptional user experience with extremely fast response times, you can hide your validation calls in the backround with out slowing them down and its intuitive.
The pain however is that it is VERY hard to unit test and you can get some extremely LARGE javascript files, also the extra coding we've had to do as our legacy systems still run on IE6 is ridiculous.
But MVVM and MVC don't have to be used exclusively on there own, we use both. But having 3 levels of validation is something that still bugs me.
advantages
This can rock.
disvantages
You can screw it.
Seriously. Making use of transporting part of the frontend logic into the browser can boost your application development why you keep more strict data-processing encapsulated on server-side.
This is basically layering. Two layers, the one above talks with the one below and vice-versa:
[client] <--> [server]
You normally exchange value objects in a lightweight serialization format like Json between the two.
This can fairly well map what users expect in a useful structure while domain objects on server-side could not be that detailed.
However, the real power will be if the server-side is not in written in javascript at some certain point because I think you can not create well domain objects there. Consider Scala (or something similar expressive) then if you run into that issue.
Ten months later after this question, I have used the both patterns inside the same application.
The only problem was the need to map the models twice.
MVC (ASP.NET MVC 4 Web API)
The most important resource was the routes.
Models were created to database interactions and as arguments for
controllers' actions.
Controllers were created to manipulate the API
requisitions and to render the views.
Views were not modeled with
server-side models, but all the resources of Partial Views and
Sections.
MVVM (Knockout.js)
Models were created with the same properties as the server-side models.
Views were binded with models' properties, and decreased a lot of the views' size.
View-models were created with the values provided from API methods.
Overall, the MVC combination with MVVM were very useful, but it needed a big expertise and knowledge. Patience is required too, because you need to think about the responsibilites of each application layer.
Whenever I want to study a new language, the best way IMO is to see how expert writes code in that language, that is always effecient.
I am looking for that :)
First you should understand that what is AJAX
Ajax is a way of developing Web
applications that combines:
XHTML and CSS standards based presentation
Interaction with the page through the DOM
Data interchange with XML and XSLT
Asynchronous data retrieval with XMLHttpRequest
JavaScript to tie it all together
Simple Ajax Example
AJAX isn't really a language in and of itself, it's used in tandem with other languages to create dynamic web applications. There isn't really a catch-all open source AJAX project that I'm aware of, although there may be some tailored to specific languages. Perhaps if you update the tags to elaborate on the language I can offer some suggestions.
Some resources you may be interested in:
http://api.jquery.com/category/ajax/
http://www.w3schools.com/ajax/default.asp
http://code.google.com/edu/ajax/tutorials/ajax-tutorial.html
For a relatively simple application, can Webflow be employed to reduce the need to create form controllers? Well, certainly it can, but I guess what I'm asking is: can and should I write an entire application using Webflow for all of the controller / view logic if my goal for doing so is to reduce the amount of code that I write?
I'm struggling my way through the (poor) Webflow documentation and am wondering if it's worth it, or if I should just stick to regular MVC.
The use case for Web Flow is to solve the problem involved with controller logic that spans multiple-page navigation (a pageflow, or wizard). If you don't have to have a form split across multiple pages (or need several small forms to participate in a single transaction), you probably don't need a Pageflow.
Most applications do need this, however. Anything more than simple CRUD stands to benefit.
Pageflows provide a natural cache for the data and can solve problems involved otherwise when using back button navigation and multiple frames/tabs.
If you are thinking about how to store data that needs to live longer than a single request (the common but misguided view is to store in the HttpSession) then you will definitely get something out of Web Flow. If you're not doing anything like that and processing everything at the request-scope then odds are you don't need Web Flow.
Update:
Web Flow can eliminate the need for specialized controller classes to accomplish following a path of page transitions/form updates along a predefined workflow. If you don't need to do this, you can save yourself a lot of configuration/complexity just by using MVC.
SpringMVC and Spring WebFlow can be used together where appropriate - there is nothing odd about that.
If you have a use-case which is simple crud and you think you could easily implement this using SpringMVC then that's probably the right choice.
Note: You could also achieve this in WebFlow too and that neither better or worst.
If you have complicated wizard logic and state management requirements then WebFlow is great plus you get many other features for free like transactions and persistence support (Version-2).