So I am working on a personal MVC project for practice. I like the responsiveness with using ajax calls to web services to update the page and not have to do an entire post back.
My knowledge is very limited and I am only aware of being able to do this with Javascript.
However, from a new developer's perspective, there is one problem with this. It would be assumed that you would need to carry out this same behavior through most of your site for any of your CRUD operations on your domain objects. Therefore causing (again for a new developer) the lack of handholding with Javascript (debugging, unit testing, strong type...etc).
But do to my lack of knowledge, is there a way you can acquire this same behavoir in MVC without having to perform all your crud operations with javascript/ajax calls to web services?
NOTE: before beating me up about my loose remarks of Javascript....I like Javascript, and there might be ways to negate some of the points I made with using it for all your CRUD operations to get the behavior I seek that I might just not be aware of.
Based on your question, it sounds like you're looking for an UpdatePanel for MVC. This control isn't valid for ASP.NET MVC, but you could accomplish similar functionality by using AJAX (either the Microsoft.Ajax lib or something like jQuery) and returning a PartialView from your controller. There's a decent tutorial on this technique on Telerik's site (just ignore the parts where they render their own controls -- you could render pretty much anything).
If this doesn't met your needs, the I believe, in order to accomplish an AJAX-like behavior on your page or pages, there will have to be some degree of JavaScript involved.
You may want to consider using a JavaScript framework like jQuery or MooTools in order to wrap the AJAX calling behavior, so that you just have to invoke the already-tested AJAX calls (e.g. jQuery.ajax()). Your JavaScript, then, would just be the callback handlers to update your pages.
On the server side, since you're using MVC (which I'm assuming is ASP.NET MVC), your controllers could just return a JsonResult instead of a ActionResult and just have your CRUD operations inside your controller instead of create a separate suite of web/WCF services. (You could also return an ActionResult to your jQuery.ajax() call, too.)
So I don't think you're going to be able to get away from JavaScript in order to accomplish AJAX-style behavior in your web site. You may not have to create a suite of web services as you could just have them contained within your controller.
This is probably going to get you what you want. You may want to check out a tutorial on the ASP.NET web site for some additional insight (but that won't get you to the unit testing part of your question).
Related
What kind of framework is Razor? Is it backend or frontend?
What is the difference between the two types of frameworks?
I'm trying to learn a little bit more about backend and frontend frameworks and since I usually work with Visual Studio Asp.net MVC was wondering about it.
It is not a framework . I think you're misinterpreting certain concepts. Razor is a server side view engine, and it uses C # or VB.NET to generate dynamic content.
Razor Syntax Quick Reference
This question is a couple of years old, but I'm going to add my two cents.
People struggle to give an answer to this question because the terms 'front-end' and 'back-end' aren't formally defined anywhere. Because of that, any answer is purely subjective.
That being said, it is my opinion that the relationship between front-end/back-end and client-side/server-side isn't necessarily one-to-one
I think it helps to think of it like this: client-side and server-side are run-times, while front-end and back-end are a separation of concerns.
'Client-side' always refers to code executing on the client's machine and 'server-side' always refers to code executing on the server. A 'front-end' developer deals with displaying data to the user and getting data from the user, while a back-end developer deals with storing, manipulating, and retrieving that data.
Consider a front-end developer who is tasked with building a UI. Much of the code they write will be the typical HTML / CSS / JS. However, they will also have to deal with the data that is passed to the front-end from the backend. This is where Razor comes into play. The front-end developer will write the Razor code (which executes on the server-side) to display the data.
That is, the front-end developer will write server-side code to help generate the UI, in addition to writing the client-side code that really defines the UI.
Now, I can't imagine a scenario where a back-end developer will write client-side code.
So, to answer your question, Razor is a front-end technology that executes on the server-side runtime. It's only purpose is to generate the UI, which is the concern of the front-end.
Razor is for writing dynamic html page which is front end and c# is for writing backend logic. Although you could move all the backend logic inside razor but its highly not recommended.
Razor allows you on the back-end more easily create views (.cshtml in C#).
It is more like templating system...
http://www.asp.net/web-pages/overview/getting-started/introducing-razor-syntax-c
I'll start some lab prototypes on some of our Web App pages. We use a lot of Postback, ViewState, UpdatePanels, ModalPopup Extenders, all the ASP.NET usual stuff. It's good enough for most cases. But I wanna push things further...
I've been playing around with jQuery for some time now. I know what's capable of. I'm thinking of TRULY substituting the ASP.NET usual things by things like $.ajax(), $.get(), etc. No more postbacks. User interface? jQuery UI. I'm truly impressed by some plugins, specially jQuery grid.
I think it's the next step into Web UI. I mean, it's ALREADY the current step! I love the power of C#, but I'm not that impressed with the ASP.NET framework. I imagine that by doing that, I'll truly separate UI from Business logic.
However:
Should I really do it?
Should the code behind be only Web Handlers and Web Services?
What should I beware of?
How about security? How to implement it?
What will I gain? I know I'll gain some in performance, since postbacks in pages with too much data takes time because of the ViewState AND I'll be transacting only XML and/or the always light JSON format. But I imagine, as usual, there will be pain...
Where will the pain be?
I'll take it slow, anyway. But I want to ask you guys: what am I getting into here?
Before I reply, I would strongly suggest that you go for ASP.NET MVC Framework. It's a totally different kind of development than the Webforms. It's a step away from ViewState and that junk. This is where Microsoft is pushing all their efforts to and this is the only way right now to build much more scalable and interactive websites on the .NET Stack.
Should I really do it?
Yes. jQuery + Ajax are very good and would let you build some very interactive and usable websites. And the way things are going right now, truth to speak if you don't use the power of Javascript at the client-side, your website would like build in 1995.
Should the code behind be only Web Handlers and Web Services?
You should only use the handlers/services to improve the design of your page. You can't build your whole website only on that. The method is to create a page, and then improve it with the services. Avoid postbacks for small details. And improve speed by Ajax etc. Making a whole website on Ajax is not a good idea.
What should I beware of?
Technically you need to understand client-side coding and how does HTTP works over the internet. ASP.NET takes does that all under the hood, so you don't even need to know but if you are doing postbacks etc. then you should understand it's limitations etc.
How about security? How to implement it?
There isn't a lot to security in Ajax as long as you do the same stuff which you did for normal postbacks e.g.s CSS attacks, SQL injections, Anti-Forgery etc.
What will I gain? I know I'll gain some in performance, since postbacks in pages with too much data takes time because of the ViewState AND I'll be transacting only XML and/or the always light JSON format. But I imagine, as usual, there will be pain...
Where will the pain be?
The pain usually is the complexity. But complexity comes with flexibility. Traditional ASP.NET was taking care of everything without you having to interfere. but now you have to make up the request, send it to server, receive the reply and then update DOM accordingly. You have to deal with all of that but on the flip side, you can deal it in whatever you want.
Hope that helps.
I say yes. Postbacks are easy for the developer and horrible for the user experience. Don't make them suffer through heavy page loads just to toggle a box on the page.
But, you need to consider the time that it will take, especially since you might have to rely on more and more javascript code (which can be finicky if you are new to it).
I've recently done it on a large project and I'm glad I did it. I moved from full page postbacks to WebMethods and web services. Try to reduce state on the server which will help compartmentalize each request handler.
Look into asp.net-MVC it is most likely what you are talking about and implements jquery and JSON calls.
If you used PostBack and ViewState you might have done that for a reason. It allows for Components and Events. Thats something you will miss in ASP.NET MVC (you dont say you want to use ASP.NET MVC, but if you say ASP.NET without PostBack everyone will understand ASP.NET MVC)
I use ASP.NET and ASP.NET MVC. ASP.NET with postback comes into play if the project is realy more an application than a website (lets say nyt.com being a website and facebook being an application ).
How would one go about creating a facebook-style "Like" button in C# ASP.NET without doing a postback? Are there any code examples or tutorials that you know of? I assume that would have to use asynchronous javascript. (this is a tough one to search for due to the Facebook keyword!)
This would have to work with .NET 2.o framework, SQL Server 2005 and VS 2005.
Thanks for any direction.
The technology you are looking for is AJAX. It is a fancy way to use JavaScript (specifically the httprequest object) and the HTML DOM to asynchronously do things on web pages.
Here is a tutorial specific to ASP.NET. It was written for .NET 1.1, but the principles are basically the same.
Suggestion: I really prefer the JQUERY AJAX implementation to the controls that ASP.NET has built in, even when working on ASPX pages. It just seems a lot more lightweight and has less magic going on behind the scenes.
I'm not completely sure what you're asking here but maybe an ASP.NET Web Service would be what you're looking for?
Here are a few links:
http://msdn.microsoft.com/en-us/library/ms972326.aspx
https://web.archive.org/web/20210304124019/https://www.4guysfromrolla.com/articles/062602-1.aspx
http://www.codeproject.com/KB/webservices/aspwebsvr.aspx
Like others said, you need to incorporate AJAX functionality and web services in your page for this to happen. One option is to use Page Methods. Another option is to write wcf services that directly emit JSON[via the ScriptService attribute] and use the callback mechanism to call these services, and handle their response in the success method to update the UI accordingly. Take a look at how to create wcf sercvices for emitting json.
What is the best approach to implement these features and which part of project would involved?
I see some example of JavaScript grids, but I'm talking about a general approach which best fits the MVC architecture.
I've considered configuring routes and models to implement these features but I don't have a clear idea that if this is the right approach to implementing such features. On the one hand, I think if we put logic in routes (item/page/sort/), we would have benefits like bookmarking and avoiding JavaScript. On the other hand if we use JavaScript grids, we can have behavior like the old school grid views in ASP.NET web forms.
I find that using HTML helpers may be useful for paging, but have no idea if they are good for sorting or not. I've looked at jQuery, tableSorter and quick search plug-ins, but they work just on the currently-fetched data and won't help in real sorting and filtering that may need to touch the database. I have some thoughts on using these tools side by side with AJAX to get something which works, but I have no idea if there are similar efforts done yet anywhere.
Another approach I looked at was using Dynamic Data on web forms, but I didn't find any suggestions out there as to whether or not it is a good idea to integrate MVC and DD. I know implementing filtering and sorting for an individual case is simple (although it has some issues like using Dynamic LINQ, which is not yet a standard approach), but creating a sorting or filtering tool which works in all cases is the idea I'm looking for. (Maybe this is because I want have something in hand when web form developers are wondering why I'm writing same code each time I want to implement a sort scenario for different Entities).
Here's my solution based on jqGrid: http://sprokhorenko.blogspot.com/2010/01/jqgrid-mvc-new-version-sources.html
It is a bit specific to S#arp Architecture and NHibernate, so I'm not sure if it suits your needs. But it's modular so for example it's easy to tweak base repository implementation.
Basically it's just jqGrid with all its pros and cons but integrated into MVC:
control all formatting and editing with attributes on ViewModel
automatic requests, sorting/filtering/paging handling
automatic CRUD handling
Can handle both DB and list based repositories
no bookmarkable routes/links...
All you need is to provide ViewModel with attribute and override couple of template CRUD methods (can be as little as just InternalConstructEntity().
You could check out MVContrib, they have pretty good grid support.
http://www.codeplex.com/MVCContrib
For LOB Applications the Telerik Controls might be a good solution.
I personally use jQuery DataTables. It's very simple and has a well-defined server-side request. I've written a plugin for jQuery DataTables with C# and MVC. It uses the standard jQuery DataTables request and manipulates an IQeryable instance accordingly.
I have before created a quick Ajax Framework for one of my projects. It was an ASP.Net Website (C#). There was not a lot of Ajax type functions so I just made a new Page with nothing in it and in the code behind file I put some code in the Page_Load method which would look for an action in the request and then call the appropriate method.
I am in the same scenario again and I am finding that I am tempted to do the same again.
I am letting the user create a new accommodation. Two of the fields that belong with accommodation are accommodation type and area. Both of these fields are maintained by the users so they can CRUD both of these fields on other pages. I was thinking that if the area or accommodation type did not yet exist it would be irritating to have to go to another page. So instead I want to give them the functionality of adding new areas and adding new accommodation types on the same form. So I have tickboxes for the accommodation type, when they click new I present them a textbox they enter the value and click add. It makes an Ajax call to the database to add the value and then a new tickbox appears if successful else an error message. Very similar for area except I will be using a drop down list.
This time however I am using some jQuery too. I am not that familiar with jQuery's Ajax libraries YET. My question is, "Is there a...
Better
Easier
Smarter
More Extendable
All of the above
way of doing this." If so can you please point me in the right direction.
Given that with VS2008 there's support for AJAX already built into the IDE (and with jQuery support coming), I think you'll find it tough to come up with something which is not only a better user experience but also a better developer experience.
The Visual Studio team not only have a lot of resources invested in making this work well, but they also know how to integrate features into the IDE, almost certainly better than you do (and with more access to do so, I suspect).
If you want to do this for fun (or as part of MonoDevelop, for instance), that makes sense - but from a productivity point of view, I'd just stick to Visual Studio.
I dont think you need to create an entirely new Ajax Framework. A lot of time and effort by many people has been put into other frameworks like the Asp.net Ajax, jQuery, and others. Take some time to learn what these frameworks provide for you and how you can use them. If you still find them lacking nearly all of them have ways to extend on their already built features.
I'm not going repeat what Jon Skeet said and I am sure twenty other people are typing; however, if you decide to roll your own, instead of using a blank ASPX page, look into creating your own Http Handler. In visual studo you can create you own quick and dirty handler. They have an extension of .ASHX. The benefit here is you avoid the overhead of the page object framework.
jQuery is in my experience a very good library with a lot of community support. Check out the jQuery IRC channel if you can't find what you are looking for in the documentation. We have an Ajax intensive application and it runs on jQuery as its core framework. We have been pleased with the results. If you are worried about size, Google hosts jQuery so your clients can cache it locally.
Alternatively, you may just want to create the proper HttpHandler(s) that will allow your client code to call server side resources without the overhead of a traditional ASP.NET Page class.
Check out this article from MSDN