Why these two tecnologies? Which are the key decisions choosing one of them? Guidelines and scenarios?
ASP.NET MVC3 provides several capabilities that Silverlight4 does not: ...
Silverlight4 provides several capabilities that ASP.NET MVC 3 does not: ...
More: what does HTML5? And ASP.NET WEB APP?
Can someone explain? Thx.
Your question is very extensive and can in my opinion not be answered without knowing what you want to do or a scenario could be.
Basically there's one important difference between the mentioned technologies: ASP.NET and ASP.NET MVC are server side technologies while Silverlight and HTML5 applications are running on a client system.
That means that you have to decide if a server application is better because e.g. you handle lots of server data that are calculated to a simple result that is transfered to the client or if you want to use a client application that usually can have a more complex UI that the user can easily use without a need of data transfer with AJAX, postbacks etc.
Of course you have to think about security, too. The more code runs on client side, the more ways exist to attack the code. Of course there are examples of server site application that are designed very unsafe but that's another point..
I would suggest that you first of all think about the result you want to achieve and then think about the technology that suites your needs.
Related
I have been getting a bit lost in the creation of my program architecture and I want to take a step back to see if I'm approaching it correctly.
I am wondering if my setup makes sense. I'm starting to think it doesn't.
I am creating intranet applications (We were creating Internet applications, but now the scope has changed). We use an onsite Active Directory (Windows Server 2012 R2). We have a SQL Server Database.
I have been building Front End Angular applications and ASP.NET Web API's to push and pull data. I am now implementing Authentication with Auth0 and it's been a nightmare.
What kind of program architecture would you setup in this scenario?
Much Appreciated.
SQL Server + Asp.Net Web Api + Angular JS forms a perfect architecture for building Single Page Applications (SPAs). This architecture is useful for building desktop like web applications, i.e. apps that runs over web but works like desktop apps.
If you can be more specific about the problem you are facing, you will be able to get better recommendations from so.
This architecture is widely adopted in many scenarios such as SPAs. With it, you will be able to keep your front-end highly decoupled from your backend services being able to support multiple front-ends on the same set of services and run quite a few integration scenarios.
Some of the downsides of such an approach will be the extra layer of complexity added to the application (which might force you to write more tests and handle different failure scenarios that wouldn't happen otherwise, for an example) and authentication routines since you will need to authenticate two heterogeneous environments (the .NET/IIS one and the JS/Angular one).
As for the authentication pain, token-based auth schemes seem the current way to go (such as Auth0) since they let you keep and send an environment-agnostic token which will be used by different layers of your architecture.
In that sense, your architecture makes sense.
However, since you're feeling some pain in its implementation, you might want to ask yourself if you really needed all of these. When you choose an architecture, you do so trying to accomplish some specific goals (multiple front-ends? specific performance requirements? maintainability? auditability?) and the more goals you try to accommodate in your architecture the more complex will become up to a point where the pains start outweighing the benefits.
So, what were you trying to achieve in the first place?
At the moment I am starting to learn Silverlight. I have expriences in ASP.NET and like the concepts of "Masterpages. Does Silverlight provides a similar concept ? I have read a little bit about the Silverlight Navigation Framework. Is this a good replacement for "Masterpages" ?
Makes it sense to combine ASP.NET and HTML (with Javascript) with Silverlight or is it more recommandable to design and write pure Silverlight applications ? Mybe in the ner future I will start to develop an intranet (business) application which will have many and complex user interaction (it should behave like a windows client applicion). I think Silverlight is the better choice than ASP.NET !? Makes it sense also to start to use/learn the WCF RIA Services immediatly ?
Are there good (VS) templates to start with Silverlight or which are a good basis / starting point for a new Silverlight application ? Unfortunately I am missing "Starter kits" on http://www.silverlight.net like the starter kits on www.asp.net !
Thanks in advance for your hints.
Silverlight and ASP.Net are light years apart technology wise, Silverlight is closer to Winforms programming than it is to ASP.net, event though it can be hosted inside an ASP.Net page.
To achieve "masterpage" type functionality, you can have a base control or page that you can inherit everything else from. Or you can have a page which acts as a shell and you can swap views in and out depending on the user's actions.
If you are writing an app from scratch, you can do the whole thing in silverlight. You can navigate from one silverlight control (hosted in an aspx page) to another aspx page (with silverlight controls in it), but there is a performance overhead when transitioning between aspx pages (they are web pages and need to be served). You should look to eliminate separate aspx pages if possible, and create it as one big silverlight application - if your application's functionality is all rolled into one application (not spread amongst aspx pages) then you can make the most of Silverlight's Out Of Browser feature.
However you should only consider silverlight if you are build web apps or interactive/streaming stuff. If your pages are going to be largely static (i.e. presenting product catalogs, or a site where the user just drills through from one page to another) then using silverlight would be overkill, you would be better off sticking with ASP.Net or ASP.Net MVC.
Masterpages does Silverlight provide a similar concept ?
Not directly but it does provide a variety of ways to acheive the goals of Masterpages. The navigation framework is mostly the sort of thing you would need to achieve the typical reason to use Masterpages.
However its also possible to achieve "masterpage" functionality more generally by creating a UserControl that has ContentControl instances at points where in ASP.NET masterpages you would have used a asp:contentplaceholder. These content controls would be bound to custom properties added to the UserControl. This completed UserControl can then be used as the "LayoutRoot" of another UserControl or Page. Note this does not require inheritence from the "master".
Does a combined ASP.NET and Silverlight app make sense?
Well thats a tricky one the answer really is, "It depends". There are way to many factors to give this a true answer. Factors:-
Is this a public app or an internal app?
How important are including rich UI features?
First time Silverlight dev will cost you, is your project able to absorbe that?
What client platforms do you need to support?
How might ASP.NET-MVC + appropriate use of JQuery size up against your requirements?
Probably others I haven't thought of yet
Is Silverlight is the better choice than ASP.NET when there are many and complex user interactions?
The phrase "complex user interactions" could mean a couple of things? Do mean complex to deliver with HTML and Javascript but simple for the user? Or is this a sophisticated app aimed at an expert user?
In either case its likely that Silverlight will start to come into its own here.
Does make it sense also to start to use/learn the WCF RIA Services immediately?
Yet again the answer depends of the type of application you have in mind. If its line of business app where data is searched, edited and reported on then (assuming you have decided to develop in Silverlight at all) definitely you should be looking at WCF RIA Services as well as the parts of PRISM that think are appropriate.
Other types of apps may not benefit from WCF RIA Services.
Are there good (VS) templates to start with Silverlight or which are a good basis / starting point for a new Silverlight application ?
There are no start kits at present. However I think you will find what you need amoung the various demos and tutorials on the silverlight learning site.
I've particular found the videos useful. If you decide to go Silverlight its well worth clearing a day or two to got through the relevent ones.
These are a lot of questions at once.
Yes, the Navigation Framework functionality is pretty much equivalent to the Master Pages concept. Even to the point that it is tracked in the URL when users navigate, so they can use the back and forward button of their browsers.
If you want to do a stand-alone Silverlight application or a hybrid pretty much depends on your requirements and on the type of application you want to develop. If it's a Line of Business application, you might be doing fine with Silverlight alone.
For a public, content/text-intensive website probably HTML with some silverlight gadgetry here and there might still be preferable.
One of the common questions asked regarding ASP.NET MVC is why should you use it over ASP.NET Web Forms? The answer generally includes ViewState and clean URLs, amongst others. Towards the end you'll find a blurb about using the right tool for the job and that they serve different purposes. However, I don't believe I've ever seen what those purposes are. So, when would you actually choose ASP.NET MVC over ASP.NET Web Forms, or ASP.NET Web Forms over ASP.NET MVC?
You don't choose ASP.Net MVC over ASP.Net, because ASP.Net MVC still is ASP.Net. You do choose ASP.Net MVC or ASP.Net Web Forms, and there are lots of good reasons to do that:
Easier to get control over your HTML
Easier to do unit testing
Few "Gotchas"
On the other hand, Web Forms do have a few points in their favor:
Easy to put simple CRUD/business apps together extremely fast
Hard to beat ViewState performance in local LAN environment
Easy to learn forms paradigm
The result is that if you're building business apps in a corporate LAN environment (which honestly is still most web developers), Web Forms is really great. In that sense Microsoft really knows their market. But if you're building an app for the public internet, you might want MVC so you can test thoroughly and be sure your pages aren't bloated with unnecessary ViewState or JavaScript data.
Additionally, something that has changed over the last several years is that even many corporate intranet applications now need to support home/remote use, making MVC more attractive to that crowd than it had been.
Use MVC if all your team members are skilled enough to manage "control over HTML", otherwise your code will turn into a tag soup.
In other words
bool useMvc = true;
foreach (TeamMember member in team.Members)
{
useMvc = useMvc && member.IsSkilled;
}
http://weblogs.asp.net/shijuvarghese/archive/2008/07/09/asp-net-mvc-vs-asp-net-web-form.aspx
check that blog !
Bottom line "separation of concerns"
I'll give you a couple purposes, with clear advantages.
If your purpose is a public facing website that will be banking on traffic, use MVC. It is optimal for search engine optimization.
If your purpose is an enterprise web-application that acts like a desktop app, I would lean towards web forms, since state management and compartmentalization of your resources into underlying server controls offers huge advantages if used correctly.
The biggest problems facing developers is managing complexity and keeping code "clean". MVC gives the developer the reins to leverage OOP to tuck away complexity and make code easy on the eyes.
Webforms will be faster to develop in the short term, but it doesn't lend itself to long term sustainability in terms of maintenance and growth.
I've worked with Web forms for 13 years and MVC for 2 years now and when I started with MVC, I had similar questions. Here are my takeaways.
Most importantly: ASP.NET's latest release is 4.6 and they were moving to ASP.NET 5.0, but MS abandoned that for ASP.NET Core, which no longer supports Web Forms (or even VB.NET). So, that alone might give you your answer when deciding what rabbit hole to go down.
That being said:
MVC I'm finding, once you get the hang of it, is WAY easier for dealing with basic forms and any sort of simple "Model", aka tables with a very simple, straight-forward set of relationships such as orders that have tables that link to users, products, etc. Once you start getting into some more complicated relationships and need to return lots of conditional sets of results, rely on parameters, have complicated stored procedures... then Web Forms is much better for dealing with this. If you don't have to deal with this level of complication, MVC makes development SO MUCH faster, especially with dealing with an approach where you already have the DB because it creates so much of the code and validation for you already
If you're not very experienced with database design, MVC does the work for you. It can literally build the database for you.
MVC doesn't have a lot of the built in controls that Web Forms does (Gridviews, FormViews, Sitemaps, Paged lists). Everything has to be written from scratch, but luckily a lot of people have already invented that stuff for you in NuGet which you can just download into your project
MVC relies heavily on the structure of your URL. The path, the querystring, etc. If you find your application needing to do a lot of form POSTing instead of GET-ting, you're going to have to do a lot of tweaking or AJAX posting. If you have a set URL that can't change, it can be a pain. It's doable, but just a little tricker (or you can just use Angular instead).
MVC has no Viewstate. If you need to hide variables from post to post and persist them, it's a little difficult. MVC Does have things like ViewBag which lets you pass data from your controller to your page, but it clears after the page is rendered. There is also something called "Tempdata" which acts like Session state, but more temporary. However, it relies on Session State which is not an ideal way of persisting data. Session variables and tempdata variables are fine for user-level data (profile information for the person logged in), but having two different tabs open by the same user can cause these session/tempdata variables to overwrite each other when you're dealing with the actual model data.
If you're at a crossroads, I'd go with MVC. MS is pushing it and support for Web Forms will likely start going away
Hi I am looking for some web framework for my prject and I found Visual WebGui
It looks amazing, but I am pesimistic to miracles :)
Can someone more experienced than me help me?
classic asp.net vs Visual WebGui
what about speed ?
what about size of data?
what about security?
have someone personal experience with this technology?
Thanks
I have used VWG for numerous projects for the past 5 years and I can tell you that it is truly a miracle :-). I have never made such amazing web applications before. Instant AJAX, no need to ever touch HTML or CSS, and the product is constantly getting better. I know it's tough to prove that I'm a real user and not with the company, so feel free to ask me more questions, I'll keep checking this thread.
I'm not a professionally trained developer, and I don't know much about the internal workings of ASP or VWG, but in terms of your questions...
What about speed ?
-It's blazingly fast. The AJAX is faster than most AJAX frameworks out there.
What about size of data?
-The data that is sent back is compressed and kept to an absolute minimum. You can use tracing tools to see for yourself. Only required UI changes and data are sent back to the client/server.
What about security?
-It's as secure as ASP. They even had a contest for $10,000 to see if someone could hack VWG - so far, no winners.
-Danny
We've been using Visual WebGui for years with great success. Our apps require ZERO DHTML/JavaScript/AJAX/JSON/CSS coding. Seriously. For web-based .NET business applications - Visual WebGui is a perfect fit. I would highly recommend Gizmox for your next web platform.
ASP.NET
ASP.NET is a stateless dev platform. Each user's current view remains on the client - the ViewState. The ViewState must be sent to the ASP.NET server for every request This makes round-trips to the server heavy, even in AJAX scenarios. In ASP.NET, the server generates DHTML/JavaScript/CSS & sends it out to the browser. This adds to the weight of each ASP.NET AJAX call.
Furthermore, the plumbing required to wire up a real ASP.NET app, complete with JSON/AJAX/REST calls, cross-browser JavaScript, DOM management, & CSS, etc. is difficult & a maintenance nightmare.
Visual WebGui - Stateful UI
Visual WebGui is truly a revolution. Visual WebGui is a stateful dev platform, built on top of ASP.NET. All user state is kept on the server. The server knows exactly what the user's screen looks like. As such, the pipeline becomes VERY thin and VERY fast between client/server. Because the server is aware of the client's current state - the VWG Server is able to perform Diff routines - so only changes to the UI are sent over the wire.
Pipeline & Screen Drawing
Additionally, the VWG Client draws its own view. In other words - the server doesn't send out any DHTML/JavaScript/CSS... instead, the Client generates this on-the-fly based on the instructions sent from the server. For instance, to create a new Button with control ID 1 - the server simply tells the client to draw "". The VWG Client knows how to draw it's own controls. With this technology - that is literaly how thin the pipeline is.
Security
For Security, Visual WebGui is fully capable of running over SSL. Gizmox also employs a proprietary obfuscation algorithm to prevent unauthorized scripts from accessing Visual WebGui JavaScript calls & DOM elements. It works extremely well.
Application Design
Visual WebGui comes complete with an amazing Forms Designer. Modeled after the WinForms Designer & APIs - writing Visual WebGui web business apps are now extremely easy to design. Drag & drop, resize, move all your controls on your Forms & UserControls, complete with Databinding.
Two-Way DataBinding
With Visual WebGui's fully supports two-way Databinding with INotifyPropertyChanged - just like WinForms. Databind your controls to your data objects (which reside on the server) & anytime those data objects change - your controls instantly update. No need for ASP.NET UpdatePanels, etc. You don't even think about it. Just write your app & whatever needs to update on the screen - will update.
Single Language Approach - Debugging and Application Manageability
One of the core benefits to Visual WebGui is its single language approach. You write & debug ALL your code in C#/VB.NET. No more hacking JavaScript/JSON/AJAX calls & maintaining web services. No more client-side debuggers / Firebug, etc. No need to know 5 different web languages to write a single application.
Imagine - writing your app in a single language. Focusing your time on solving your business needs, not software hurdles & plumbing. Hiring & finding qualified developers also becomes much easier.
Visual WebGui instantly makes this a reality. Write business web-apps like you would a business desktop-app.
Summary
It truly is a revolution in developing web-based, .NET enterprise business applications.
I hope this helps to explain why Visual WebGui is seriously worth looking into for your next web-based enterprise business application.
Sincerely,
Ryan D. Hatch,
Customer & Visual WebGui MVP
My name is Eyal Albert from gizmox the company behind Visual WebGui.
I hope it's not to late to answer this :-) but i was referred by a friend to your question.
But i have some info for you.
The need for speed.
http://visualwebgui.com/Gizmox/CIOs/WhitePapers/tabid/528/ArticleType/ArticleView/ArticleID/390/PageID/386/Default.aspx
See the test that MVP Victor Zychla did.
Size of Data you can see our show cases.
http://visualwebgui.com/Gizmox/Showcases/tabid/358/Default.aspx
Security
http://visualwebgui.com/Gizmox/Technology/Security/tabid/624/Default.aspx
All this links are new info compared to when you asked your question i hope you find it effective.
For more info you can contact me eyal.albert(AT)Gizmox.com
The company where I work created this application which is core to our business and relies on the web browser to enforce certain "rules" that without them renders the application kinda useless to our customers. Sorry about having to be circumspect, An NDA along with a host of other things prevents me from saying exactly what the application is. Essentially, JavaScript controls certain timed events (that have to be accurate down to at least the second) that make it difficult to control with ajax/postbacks etc.
My question is this: how hard is it to convert an ASP.NET application to SilverLight assuming that most of the code is really C# business logic and not asp.net controls? I just got finished listening to Deep Fried bytes and the MS people make it sounds like this really isn't that big of a deal. Is this true for web apps, or mainly Win32 ones?
I know the asp.net front end is fundamentally different from SilverLight, but there is a bunch of C# code I would like to not have to rewrite if necessary. The replacement of the javascript code to silverlight I am assuming is trivial (i know bad assumption, but I have to start somewhere) since it deals with timed events, so I am not really concerned with that. I need to come up with a solution on how to mitigate this problem, and I am hoping this is a middle ground between: do nothing and watch us get pounded by our clients, and rewrite the whole application in something more secure than a web page with only front end validation. Has anyone tried to convert ASP.NET code to a SilverLight project?
If the bulk of your application is on the back-end, you should still be able to keep the majority of the code intact and only replace the front-end. However, Silverlight requires an understanding of WPF, which is dramatically different than the HTML/JS that your app currently uses. I'd say if your UI is pretty thin, it should be pretty easy to port to Silverlight, but the more business logic is in the UI, the harder it will be.
How heavily do you use the class libraries, and things that might be considered 'dangerous', like pinvoke, file system access and System.Diagnostics.Process?
Porting code from ASP.NET to Silverlight is not an easy task. As Nate points outs it depends on how much of ASP.NET application is AJAX based, and how much is based around server controls.
Silverlight is a state full client side technology, meaning everything is running on the client inside the browser. ASP.NET is a server technology, and is built around a request/response model. Since these two are completely different paradigms it's not a straight port.
However, since ASP.NET is just HTML and HTTP POST of form data people have done experiments where they have added a Silverlight application directly on top of an ASP.NET page, and manually built the HTTP POST request by hand sending back the exact data the ASP.NET application work. It's almost like doing "screen scraping" for your own application. This could work, but wouldn't be optimal. You wouldn't get a performance increase as your ASP.NET application would have to go through a full page cycle on every request.
A better alternative is to start out wrapping any functionality the user has in the APS.NET application as web services. You can add these services alongside your ASPX pages, and gradually port the application over. The UI you would build from the ground up based on these services.
Good luck!