Is it feasible to write an ASP.NET MVC2 application that uses the Cache Manifest mechanism to support offline processing? I know this might sound like a contradiction in terms, but I have an MVC2 web app and I'm looking at trying to make it resilient to unreliable network connections.
Of course that it is possible. The HTML5 offline storage is independent of the server side technology. Here's an example with ASP.NET. In this example the illustrated custom IHttpHandler could be easily replaced by a controller action in an ASP.NET MVC application.
Related
I have an application which is built in ASP.Net WebForms and Silverlight.
There is another WCF services application which is accessed by silverlight part of my application.
Now I have to Re create the whole application in an MVC Single Page Application(SPA) and of course the WCF one because now I would need Web API for that.
An initial solution comes into mind is to add a web api project into wcf services application and start creating web methods there and call wcf methods from there if that functionality was already there.
And for webform start a new spa with mvc project from scratch and use durandal or any other spa client framework(hell of coding).
Any useful solution/advise? as I am looking for simplicity.
I searched around and found some questions but really did not helped as they are about merging with existing apps.
Note: application is a large application with a lot of functionalities
You have to decide how confident your team is with client side frameworks. Development of Single page applications may not be easy in the beginning, but you will get used to it very quickly. It's very important to give your team the right training.
In my opinion, Durandal is the simpliest, most elegant and complete framework to build enterprise level SPAs. It is important to know how knockout, requre and durandal's router and composition work. For data centric application I would use breezejs to manipulate and cache data on the client side and request it from the server side. Breeze works best with Entity Framework on the server side, but it's not necessary. If you can use Entity Framework, it will simplify your development, because it can generate metadata of your database structure for breeze. If Entity Framework is not an option, metadata can be written by hand.
I would make server side as thin as possible. Serving data from your database using web api with ORM of your choice and some cshtml pages.
Durandal Get Started is a good place to start.
Durandal Auth is a very good template for enterprise level SPA. It may not suit you completely, but you can use it as a guidance to build different modules of your application.
Breeze samples I suggest you consider using breeze. There are good courses available on pluralsight.
Knockoutjs has good training on data-binding.
I'm new to PhoneGap and everywhere I looked doesn't suggest anything about using webforms as server code.
The application server is normally a web server (Apache, IIS, etc...) and has a server side scripting language such as ColdFusion, Java, .NET, PHP, etc... PhoneGap is agnostic of back-end technologies and can work with any application server using standard web protocols. The application server performs business logic and calculations, and generally retrieves or persists data from a separate data repository - this is normally a relational database, but could be any structure or mechanism for data persistence.
http://phonegap.com/2012/05/02/phonegap-explained-visually/
This article however, mentioned that PhoneGap is able to work with just about any application server including .Net.
Has anyone used PhoneGap with webform before? Do they work?
What about the form postbacks etc? Or everything should be AJAX-based? (Calling webmethods etc)
From the end of the linked article:
PhoneGap applications generally do not talk directly to a database;
communication is routed through an application server. The client
to application server communication can be based upon standard HTTP
requests for HTML content, REST-ful XML services, JSON services, or
SOAP (or websockets if your OS supports it). These are the exact same
techniques that you would use in a desktop-browser based AJAX)
application.
The client-side architecture generally uses the single-page
application model, where the application logic is inside a single HTML
page. This page is never unloaded from memory. All data will be
displayed by updating the HTML DOM, data is retrieved from the
application server using AJAX techniques, and variables are kept
in-memory within JavaScript.
So yes, in general you wouldn't use postbacks, you would use Ajax calls back to the server in order to get/create/update data - which is supported by asp.net webforms via handlers (ashx) or even static page methods on an aspx page. Your actual front-end you just design in HTML and CSS, no asp.net controls, just plain old html inputs, etc.
I'm a complete beginner when it comes to ASP.NET but I want to learn it in order to build a web application that eventually will communicate with a cloud hosted SQL server. However, I cannot find any information that outlines the difference between ASP.NET web application and ASP.NET MVC2 web application (in visual studio 2010) so I'm not sure where to start. Can anyone give me a simple explanation/outline so I can decide on a tutorial to follow?
Thanks
ASP.NET is a web platform. It provides a layer that sits on top of IIS (the web server) which facilitates the creation of web applications and web services. ASP.NET MVC is a framework specifically for building web applications. It sits ontop of ASP.NET and uses APIs provided by ASP.NET. ASP.NET Web Forms is another framework specifically for building web applications, and the new ASP.NET Web API is a platform for building web services.
ASP.NET, at its most basic level, provides a means for you to provide general HTML markup combined with server side "controls" within the event-driven programming model that can be leveraged with VB, C#, and so on. You define the page(s) of a site, drop in the controls, and provide the programmatic plumbing to make it all work.
ASP.NET MVC is an application framework based on the Model-View-Controller architectural pattern. This is what might be considered a "canned" framework for a specific way of implementing a web site, with a page acting as the "controller" and dispatching requests to the appropriate pages in the application. The idea is to "partition" the various elements of the application, eg business rules, presentation rules, and so on.
Think of the former as the "blank slate" for implementing a site architecture you've designed more or less from the ground up. MVC provides a mechanism for designing a site around a pre-determined "pattern" of application access, if that makes sense. There's more technical detail to it than that, to be sure, but that's the nickel tour for the purposes of the question.
Good luck!
ASP.NET MVC2 web application is based on MVC pattern in order to facilitate unit test, without mocking pipeline asp.net, because it's very difficult. you don't have code on Code Behind in order to separate your code graphic and your code functional.
With MVC your application become independent from view. you can replace easily technology of creating view.
Read this article it's very interesting : http://msdn.microsoft.com/en-us/magazine/dd942833.aspx
If you have VS10 make a small ASP.NET (webforms) application and a small ASP.NET MVC 2 application, and examine the differences between them. It's a great way to learn.
A very good material is available here
http://www.webdevelopmenthelp.net/2013/10/Difference-between-ASP.NET-WebForm-And-ASP.NET-MVC.html
Like ASP.Net web forms, ASP.Net MVC is development model to build web application in Microsoft .net framework. The major difference between them are ASP.net MVC is based on the MVC architecture. Where we have 3 independent tiers – Model, View Controllers which interact which each other to render HTML output.
Major differences
Web forms is mainly has an event driven model. Where we have page level events(Page_load, pre render, page_init etc) and control level events. Which is not the case for MVC. The request life cycle is comparatively complex.(why complex because, the request has to goes through all the events before rendering the HTML output )
Web forms is basically has an aspx page which contains UI controls and a code behind file. All the page level events and control level events are handled here. In MVC the View, Model , controller can exist independently (gives clear separation of concern)
The SOC makes it easier for development as we can have separate developers for View(design html) and controller (implement business logic)
Because of this tight coupling nature, web forms are not suitable for unit tests. In MVC we can write unit tests at both controller level, action method levels. Here we can mock the data to be passed to view and do assert the result from the action method for their different properties like view name, model properties, null check etc
In web forms we have state full behavior. The server controls in ASPX page uses view state to retain their state during request response cycle. Since this view states are stored as hidden controls inside the page itself, and they are sent during request and response cycle, it makes them more heavy. Absence of view state and state less nature of MVC make it more light weight. Hence they are much more faster in request lifecycle.
ASP.NET is a web platform. It provides a layer that sits on top of the web server which facilitates the creation of web applications and web services. ASP.NET is a framework specifically for building web applications. It sits of ASP.NET and uses APIs provided by ASP.NET. ASP.NET Web Forms is another framework specifically for building web applications, and the new ASP.NET Web API is a platform for building web services
ASP.NET is a 2 tier application in which no separate section for the database and MVC is a 3 tier application in which view and logic is kept separate.
In ASP.NET for each .aspx form one URL is generated, but in MVC the url's are generated based on the controller and by the router configuration.
I have a .net application running on server. Now I want to comunicate between my ASp.NET website and the server application.
Currently I use database, server writes info to the db and site uses it etc. However adding new fields to echange and exchanging complex object is a pain.
Is remoting the way out? If yes, what are the common things to keep in mind while doing this.
both server and asp.net site is on the same server
both is under my control
is there any other better way than using remoting?
It is .NET 2.0
The purists will say that remoting is an old, dead technology, and the way to do it now is to use WCF.
If you're attempting to have some SOA thing, the best thing is to a web service for your server application and access it from your ASP.net website application. It's the best way to do.
However I don't really understand what the purpose of the "server" is? Couldn't your ASP.net website - as you say - be your front-end of the server application?? Your "server" would then simply be the business and data layer and there would be no need to use remoting or WCF.
I would say webservices if want to stay .net 2.0, otherwise it think you should take a look at WCF.
If you need direct interaction between assemblies (ASP.NET and some server application or service) you should use Application Domains and cross-domain calls (some good example here) or using WCF, which is better. Also you can use web services if your server application can be accessed via web without major resulting drawbacks (security issues, server deployment change, etc.).
Actually, u can deploy a WebService on that server. WebService is base on SOAP, it can exchange data object with your website.
If you can update to .Net Framwwork 3.5, you can try to use WCF instead.
I've just been tasked with building a web application using ASP (.net) and am looking for some advice on where to start. In a nutshell the application needs to be able to.
Handle user verification / authentication
Handle sessions
Do SOAP messaging
The application is intended to act as a front end for system functions that are accessible via web service calls.
I intend to do a lot of work on the client side using JavaScript and am thinking of using ASP solely as the framework for the 3 items I listed above.
Appreciate any suggestions you may have.
Use Visual Studio 2008 if you can. Its support for Ajax client libraries and javascript intellisense is very good. (Check out the jQuery add in)
ASP.NET has built in Login controls (and the membership services mentioned by ChrisE), and also has Forms Authentication. Try to leverage these existing components and avoid using session to store user specific objects/data.
---session rant
Its sometimes unavoidable, but you should avoid it whenever you can. It incurs a burden on the webserver for each user, and that leads to some very difficult scaling problems. The FormsAuthentication Ticket has a value property that you can store about 4K worth of user data in - try to use that instead.
---End session rant
Try to use a MVC approach (not necessarily an ASP.NET MVC), but at least one that seperates your presentation / view layer from the data / model layer.
Create a default theme and use it. Most sites will need to have multiple themes later, and refactoring that will be a PIA.
If you need SOAP to interact with Non-.NET services then by all means use it. If you are only connecting to .NET services then look into WCF clients and services. They will give you more flexibility.
If you are doing the client work in javascript, then dont use the update panel. It adds lots of overhead.
Get FireFox + FireBug + YSlow, and IE8 (yeah its beta still). They will help you when dealing with the client end of debugging / styling.
Take a look at the rules for website performance, but take these with a grain of salt. They are intended for very large sites, and some of the items may not be applicable (CDN, DNS lookups, Redirects).
WCF for Soap -- I would also suggest picking this up:
alt ASP.NET 3.5 http://ecx.images-amazon.com/images/I/518N8vYWf1L._SL500_AA240_.jpg
This book is in tutorial form -- and Jesse Liberty is a great teacher (as are his co-authors).
ASP.NET provides out of the box authentication/authorization through the SqlMembershipProvider and SqlRoleProvider classes, or you can use the ADMembershipProvider along with a custom RoleProvider to authenticate and authorize against an Active Directory setup.
Session handling is readily provided by ASP.NET as well, through an in-process server, an external StateServer service, or through a connection to SQL Server (and of course, you can provide a custom Session service if you need something different).
As Lou Franco mentioned, WCF provides the framework for the SOAP calls, and will blend in with your ASP.NET application quite handily.
If you are using ASP.NET Web Forms then for handling user authentication/verification I'd recommend ASP.NET Membership services http://msdn.microsoft.com/en-us/library/yh26yfzy.aspx because it does some of the heavy lifting for you and also helps you from making any elementary security mistakes.
This is not directly related to your requirements, but I'd suggest you study the differences between Web Site and Web Application. The sooner the better. Everything will go smoother if you understand how the project is managed.
You can start here: http://www.codersbarn.com/post/2008/06/ASPNET-Web-Site-versus-Web-Application-Project.aspx