What is the preferred method of returning data from a class, through JSON and then constructing the HTML on the clientside, or by constructing the HTML in the returned data?
Thanks
JSON is the preferred method. It makes for a more scalable solution which is not dependent on the consumer of the services that you are using.
That depends on the nature of your application. If you want to build a list, for example, that makes sense to have a web method return a JSON, have a template of the list item and construct the DOM using jQuery or something similar (or even by hands). However, sometimes that may make sense to return an HTML (e.g. if you need to get a themed template of the list item), but then you will once again return to JSON for data.
The MVC framework provides extensive support for producing HTML server side, using controllers and views to give structure. I would suggest some reading on this, http://www.asp.net/mvc.
Your question can pretty much be translated to: "Do I choose ASP.NET WebForms or ASP.NET MVC?" in terms of Microsoft technologies. In my honest opinion WebForms or constructing HTML on the server is a bit outdated and the more modern approach, the MVC, is better in terms of scalability as mentioned above. Delivering JSON to the client allows you to reuse data services across your views (pages) and render different front-end depending on how your application evolves, which the server-side rendered HTML is hard to modify.
Related
on one of the project I was delegated to I saw some c# code like this
string.format("some JavaScript function(){{ {0}.setValue and do magic",param1,param2,...");
Then the function was set as index changed method of some JavaScript element.
It's not the first time I saw it but its the first time it struck me so hard. The actual code was enormous and there was large number of parameters passed.
I was wondering if there is a better way (Probably plenty?) cause this seemed for me like a poor one. Writing complex javascript logic can be painful and writing it using string.format is semi insane for me. Can some 1 explain to me what are the alternatives and best practices are?
Thanks for help.
Regards.
If you have not some really need of generating conditional javascript code for the client, bacause that is what the presented code is doing, I would strongly advice to keep JS on client, and deliver it to the client via different standard mechanisms available in browser.
In short
use client side JS delivered via JS files or like a text and after treated like JS, but this is often for advanced scenarious.
use any MVC framework on client side, to avoid continue callback to the server, if you don't really need it, and manage states and appearance of content on your site in easier way.
a) knockout
b) angular.js
... many others...
I'm hoping someone can advise me on how to solve my networking scenario. Both the client and server are to be C# / .NET based.
I basically want to invoke some kind of web service from my client in order to retrieve both binary data (e.g. files) and serialised objects and lists of objects (e.g. database query results).
At the moment, I'm using ASPX pages, using the query string to provide parameters and I get back either the binary data, or the binary data of the serialised messages. This affords me a lot of flexbility, and I can choose how to transmit the data, perform simulatanous requests, cancel ongoing requests, etc. Since I can control the serialised format, I can also deserialise lists of objects as they are received which is crucial.
My problem isn't a problem as such, but this feels a little hack-ish and I can't help but wonder if there are better ways to go about it. I'm considering moving on to WCF or perhaps another technology to see if it helps. However, I need to know if it helps with my scenarios above that is;
Can a WCF method return a list of objects, and can the client receive the items of this list as they arrive as opposed to getting the entire list on completion (i.e. streaming). Does anyone know of any examples of this?
Am I likely to get any performance benefits from this? I don't know how well ASPX pages are tuned for this, as it surely isn't their primary purpose.
Are there any other approaches I should consider?
Thanks for your time spent reading this. I hope you can help.
WCF does not natively support streamed collections. (Which are not the same as Streaming Message Transfer)
However, see this blog post.
I recommend that you use ASHX files (Generic Handlers) instead of ASPX pages (Web Forms), as they have far less overhead.
i have read this article ScuttGu
for making use of User control to make Client side templates.
and this one too
Ecnosia
are they the same, regarding performance ?
OK Encosia's (Dave Ward) example uses the JQuery plug-in JTemplate to do its works.
ScottGu's utilizes more of the ASP.Net stack.
That said, ScottGu's sample lacks some fineness.
As for performance...I hate that question. Too many variables. But...
ScottGu's example will be moving more bits over the wire. You are essentially sending the entire html output to the browser via a web service call.
Encosia's example is sending the rawest form of data possible (JSON) to the browser, and then turning it into html using JQuery/JTemplate/Javascript.
In theory Encosia's example will perform better. Less data moved over the wire, should be less server load as well. But it will be more browser work (nominal at best here).
That said, for small amounts of data, I doubt it would matter either way.
Both samples use JSON, which you get for free when you use .NET Web Services. So the amount of data which goes over the wire will be the same.
On the client-side, don't know about about the client-side performance of the library generated by ScriptServiceAttribute, but the differences between doing it yourself and using that library should probably be marginal.
The Ecnosia example uses jTemplates. jTemplates can give you a good boost in performance when it comes to fetching large lists and displaying them in repeating sections (like html tables).
reply to devmania:
Scott's version applies the template server-side, and then sends html+data formatted to the client. The html here can be a real overhead (in case of a table, think about all the tr's, td's, style properties, spacing between tags...).
jTemplates renders client-side. The data is send in the more data efficient and compact JSON format (just the data, not the html). The template that jTemplates has to read is also much smaller, as it only contains the definitions for first row.
Yes, it is much easier to render server-side. Server-side can also be more flexible in rendering, as you can access data sources which you don't have on the client-side.
Client-side can in many cases be more efficient. Further, with some javascript, you can make it as flexible as server-side rendering. But, I reckon complex client-side rendering would take more time to develop.
Is there a pattern where in WPF, I can build a simple UI form from an XML like definition file pulled from a database?
It would allow the user to enter data into this form, and submit it back. The data would be sent back in an XML structure that would closely/exactly mimic the UI definition.
The definition should include the data-type, and if it was a required value or not. I would then like to map these data-types and required values to Data Validation Rules, so the form could not be submitted unless it passes the check.
It should also handle the ability to have lists of repeating data.
I am in the planning stages of this project and have fairly good flexibility in the design at this point, though I am pretty sure I need to stick to the desktop, not web since I may be doing some Office Inter-op stuff as well.
What technology stack would you recommend? I think XMAL and WPF may be close to the answer.
I have also looked at XUL, but it doesn't seem ready or useful for C#. (Found this article from MSDN in 2002)
Thank you,
Keith
Model View Presenter seems to suit WPF quite well, if you've not heard of it before check out the Supervisor Controller pattern, which is a subset of MVP (the author has renamed it to Supervisor Controller and Passive View as two different flavours of MVP). It is a design principal that will help you promote the separation of concerns and works much better than MVC when you don't have a framework to physically enforce it.
You could always try to create a view engine for ASP.NET MVC that works with WPF though, that would be nice.
Well if you wanted to roll something yourself, you can load and render dynamic XAML pretty easily. Rather than have users create XAML directly you could have a subset of it "mapped" to an XML format of your choosing that you XSL into valid XAML:
XmlReader tXml = XmlReader.Create(myXamlString);
UIElement MyElement = (UIElement)XamlReader.Load(tXml);
What about Caliburn?
You might want to consider taking a look at the CSLA.NET framework. You can read about it here along with info on a well written book that's available:
http://www.lhotka.net/Default.aspx
-Eric
I'm looking at converting a web site from classic ASP to ASP.NET. I'm thinking of doing an agile style approach and providing deliverables as quickly as possible and so am thinking of doing a line by line conversion and creating "bad" ASP.NET and have it all in the ASPX file for phase 1 and get that working. That, I figure, will be the fastest and safest (i.e. preserving identical functionality). The next phase would be to split the code out into codebehind and multi-tiers.
I plan on replacing the VBScript in the ASP files with C# in the ASPX files.
So apart from general comments about what I'm planning on doing (which I welcome) the specific question that I have is: Are there any helper functions out there that wrap the VBScript functions from ASP to a C# equivalent that someone's already done?
So I'd be looking for a C# file (library) that has wrappers like:
string Mid(string txt,int start,int length)
{
return txt.SubString(start, length); // or is it start - 1?
}
double Abs(double num)
{
return Math.Abs(num);
}
Look in the Microsoft.VisualBasic namespace to get access to the old VBScript/VB6 functions. You can use them directly from C#.
Additionally, you're in for a shock. ASP.Net uses a different compiler model, and so some of the things you did in Classic ASP aren't allowed at all in ASP.Net. Include files is the big one that comes to mind-- all of your supporting code (code outside of the *.asp file for the page itself) must be re-thought to support the new model.
I don't think a line-by-line approach is a good idea - you'll just end up with a bunch of bad code that you'll still have to refactor. That doesn't sound very Agile to me either.
I'd try breaking the site up logically into modules, and then try rewriting specific pages or modules as ASPX. For example, if the site has an admin section, maybe you could just rewrite the admin portion. Then repeat for the next section. This could be done iteratively for each section until you're done.
I agree with the comment by Jason, and would like to also point out a higher level issue that you'd have to address, if you haven't thought about it already.
Does your classic ASP site make use of session variables to manage state between pages? If so, have you thought about how you're going to share session state between ASP and ASP.NET? Classic ASP and ASP.NET implement session state in different ways, so you will need methods to transfer between the two.
Smaller applications may be easier to "convert", but if you've got a large app that makes heavy use of session variables, you may want to think about other options.
If using ASP.NET MVC is an option for you, I'd take a look at that first. I would think it would be a much easier translation than trying to go from a scripting language to WebForms.
I don't think you gain anything by redoing the site as-is in .Net. Implementing it properly will be so radically different than what you'll start with in .Net that it just seems like wasted effort. Furthermore, it will be very difficult to write unit tests if you implement everything in .aspx pages without even code-behind.
I would aim for an MVC conversion. If you do port it over as-is, at least investigate master pages, that should save you some headaches.