Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 1 year ago.
Improve this question
The company I work for has an existing product which is a Delphi 32 bit windows application.
The application has a spreadsheet like UI which requires a very fast data grid/table view and advanced charting (plus the usual button/dropdown/menuing/toolbar controls).
We also have a .net 3.5 ASP.NET application which mirrors large parts of the business logic in the windows app.
We want to re-write the delphi application in .net, so we can have one set of business logic code.
We would like one application if possible (which is why we are looking at Silverlight).
What do we lose in going from WPF to Silverlight? Should we use neither, and use WinForms instead? or should we just further enhance the ASP.NET/AJAX application?
WPF is currently more flexible but both WPF and Silverlight are slowly merging. If you want the ability to access the application in a browser go Silverlight, otherwise WPF.
The charting may be a bit of an issue depending on how complex it is. So far there isn't many charting packages available for WPF or silverlight. ChartFX is decent but doesn't support advanced financials such as MACD etc..., which there is a financial pack available in the winforms version.
Another consideration would be if this application is for internal or external use? If it's external I would say stay away from silverlight as the adoption isn't quite there yet. If it's internal and you control the standard then definitely do silverlight vs asp.net MVC.
If you are not tied to an existing Winform app, and you plan on doing a lot of design work, then WPF or Silverlight should be higher up on your priority list. The main benefit of WinForms today is that they are more mature and have more 3rd party components, but XAML is becoming more popular and opens new doors in terms of application GUI design.
The choice between Silverlight and WPF mainly pivots on your distribution method and application requirements. Silverlight apps are usually accessed via a web page, and while there are methods of accessing them offline they really work best in lightweight situations. WPF apps run in "Full trust" mode and have many features that are not available even in Silverlight Offline applications. If you are talking about a simple data entry or Line of Business application, Silverlight should meet your needs, but if you need access to external resources (Hard Drive, local database, USB device, etc) then you may be stuck with a WPF application. I believe that WPF apps can use Click-Once deployment, which gives you may of the benefits of a web-deployed application while retaining full access to the underlying hardware.
WPF vs Silverlight
I would go for WPF, even if you have some fancy control etc. in WinForms you can always host it in WPF.
UI which requires a very fast data grid/table
WPF uses DirectX and Redering is much faster. Also you have one more way - XBAP.
On the other hand, ASP.NET/AJAX is more multiplatform.
WPF = fast rendering, ASP.NET/AJAX = multiplatform.
Silverlight is not that mature.
just go througth this reference also
Choosing between WPF and Silverlight
Silverlight is largely a subset of WPF (that's an oversimplification, but the general point remains). Frankly, you don't lose a whole lot by using it over WPF -- in fact, the XAML differences between the two are enough that making one Silverlight solution is going to be easier.
In any case, I'd say that either are better than WinForms, which throws out the web interface altogether. Also, Silverlight/WPF has a generally better rendering engine, and allows for easier separation of display and business logic.
Related
I am a Web developer in ASP.Net. Just I heard about WPF.Is WPF is for Desktop stuff or can
i use all WPF controls in my web application?. When i visit the microsoft website it talsk much about designer tools (expression,blend),where can i get web developer perspective vidoes of WPF (Just drag the control on my form and set the properties for coding)?
Bottom line is this - WPF is a desktop technology. It's very closely related sibling - Silverlight requires a runtime much like Flash to run in the browser.
Silverlight components/controls/applications can be hosted inside of an asp.net application but the idea that your skills will just 'carry over' is grossly misguided. Silverlight uses the same core languages (C#, VB.NET etc and a subset of the .NET Framework) so to that extent that knowledge is valuable but both WPF and Silverlight use a declarative presentation language called XAML or (XML Application Markup Language). XAML is what HTML can only dream to be - it is extremely powerful and elegant and has rich support for things like binding.
From a tooling perspective - Expression Blend is really a XAML designer that can target Silverlight or WPF applications.
Videos can be found at
http://windowsclient.net/learn/videos_wpf.aspx
http://silverlight.net/learn/
http://microsoftpdc.com/Videos
UPDATE: Ray makes some good points in the comments section about WPF controls and the XBAP type (Xaml Browser Applications)
If you are developing intranet applications, you might also consider WPF XBAPs(XAML Broswer applications). Clickonce enables very interesting deployment scenarios of WPF XBAPs in intranet environment.
WPF XBAPs can provide more features than silverlight because XBAPs can make use of full .NET framework. Having said that silverlight is really amazing for developing Line Of Business applications.
Hope this helps.
You CAN use WPF for your web application. I have done so on several occasions.
To deploy WPF to a web browser you wrap your content in Page controls and create what is called an XAML Browser Application ("XBAP"). XBAPs can do almost everything that a full WPF application can do except access the local computer and call unmanaged code.
At present XBAPs are significantly more powerful than Silverlight, though that gap is closing quickly. I expect in another year or two Silverlight will be as good as XBAP for web deployment.
WPF is solely for desktop applications. Silverlight is very similar to WPF however and can be used as a Flash replacement, so your skills carry over.
If you are looking for WPF beginner videos to start with, then try these:
http://windowsclient.net/learn/videos_wpf.aspx
Hope, it will be helpful.
Why would you consider using ASP.Net MVC or standard ASP.Net with forms and controls for a web project? Apart from personal preference what would be the reasons? What sort of projects do you find more suitable for MVC and what projects for normal ASP.Net?
Would you consider transferring your current projects to one or another?
ASP.NET Web Forms and MVC are two web frameworks developed by Microsoft - they are both good choices. Neither of the web frameworks are to be replaced by the other nor are there plans to have them 'merged' into a single framework. Continued support and development are done in parallel by Microsoft and neither will be 'going away'.
Each of these web frameworks offers advantages/disadvantages - some of which need to be considered when developing a web application. A web application can be developed using either technology - it might make development for a particular application easier selecting one technology versus the other and vice versa.
ASP.NET Web Forms:
Development supports state
• Gives the illusion that a web application is aware of what the user has been doing, similar to Windows applications. I.e. Makes 'wizard' functionality a little bit easier to implement. Web forms does a great job at hiding a lot of that complexity from the developer.
Rapid Application Development (RAD)
• The ability to just 'jump in' and start delivering web forms. This is disputed by some of the MVC community, but pushed by Microsoft. In the end, it comes down to the level of expertise of the developer and what they are comfortable with. The web forms model probably has less of a learning curve to less experienced developers.
Larger control toolbox
• ASP.NET Web Forms offers a much greater and more robust toolbox (web controls) whereas MVC offers a more primitive control set relying more on rich client-side controls via jQuery (Javascript).
Mature
• It's been around since 2002 and there is an abundance of information with regards to questions, problems, etc. Offers more third-party control - need to consider your existing toolkits.
ASP.NET MVC:
Separation of concerns (SoC)
• From a technical standpoint, the organization of code within MVC is very clean, organized and granular, making it easier (hopefully) for a web application to scale in terms of functionality. Promotes great design from a development standpoint.
Easier integration with client side tools (rich user interface tools)
• More than ever, web applications are increasingly becoming as rich as the applications you see on your desktops. With MVC, it gives you the ability to integrate with such toolkits (such as jQuery) with greater ease and more seamless than in Web Forms.
Search Engine Optimization (SEO) Friendly / Stateless
• URL's are more friendly to search engines (i.e. mywebapplication.com/users/ 1 - retrieve user with an ID of 1 vs mywebapplication/users/getuser.aspx (id passed in session)). Similarly, since MVC is stateless, this removes the headache of users who spawn multiple web browsers from the same window (session collisions). Along those same lines, MVC adheres to the stateless web protocol rather than 'battling' against it.
Works well with developers who need high degree of control
• ASP.NET web forms automatically generates much of the raw HTML you see when an page is rendered. This can cause headaches for developers. With MVC, you have complete control over what is rendered and there are no surprises. Even more important, is that the HTML forms typically are much smaller than the Web forms which can equate to a performance boost - something to seriously consider.
Test Driven Development (TDD)
• With MVC, you can more easily create tests for the web side of things. An additional layer of testing will provide yet another layer of defense against unexpected behavior.
Authentication, authorization, configuration, compilation and deployment are all features that are shared between the two web frameworks.
WebForms is an abstraction which hides the mechanics of the web from the developer. It allows desktop developers to relatively easily transfer their skills to the web. Whilst it does achieve this in part, in practical scenarios it is usually not long before the abstraction breaks and one has to put in messy workarounds. Unit testing is difficult, because the logic for handling user interactions is tightly coupled with the UI. The HTML produced by a typical WebForms app is far from optimal. It is typically bloated, difficult to read and contains a lot of content which is present only to allow the abstraction to work, e.g. viewstate, which is a huge blob of information to help the abstraction give the illusion of state to the developer, even though the web is a stateless medium.
MVC, however, embraces the mechanics of the web. The fundamental operations which take place in a web request and response are presented to the developer as simple abstractions. MVC has a clear separation of concerns. The model simply represents the business objects or entities with which the system is concerned, with methods for retrieving and storing instances of these objects. The controller take a web request, performs operations against the model, and then hands the model to the view. The view is purely a renderer, for presenting the model to the user and exposing interface items which allow the user to formulate the next request to pass to a controller. This separation of concerns allows for relatively easy unit testing. The developer has complete control over the HTML produced and there is no need for other artifacts to be present (e.g. viewstate).
I prefer MVC. For rare occasions it may be useful to use Webforms, e.g. a quick prototype or demo, but otherwise I would always recommend the use of MVC.
As for transferring a project from Webforms to MVC, this is obviously very subjective and dependent on the application itself, and budgetary constraints, but in general I believe this is a step in the right direction.
You can find many differences, advantages about the ASP.Net MVC over the normal ASP.Net
Applications. if not kindly visit stack overlow page.
Biggest advantage to using ASP.Net MVC vs web forms
the reason for choosing the MVC concept for your application vary on many things
What for your application for ? either kind of forum, reporting tool or intranet website
Whether you want to follow desing pattern or not?
if yes, then whether is that going to be MVC or any other ??
Whether you need modularity for future enhancements?
Whether you need full control on your code?
Better support on the testing part from the developer perspective should be there or not?
If are sure about those things, then you can move ur appln to MVC framework model.
Other wise its better to continue with ASP.Net Web.apps, because it includes all the latest
features what the current industry needs.
I have a web application built in the asp.net 2.0 MVC pattern.
Now the clients want to update this application with rich UI experience and the latest .net technologies.
Can anyone suggest whether I should use WPF or Silverlight: which one should I choose to change the application per the client requirement? I should be able to reuse my business layers and data layers, and thus reduce the time of development.
If I should choose one of these, please tell me the reasons and describe the requirements and what other guidelines I should keep in mind.
Thanks in advance
SA
First lets clarify the technologies:
WPF is a desktop technology - although you can run it via a web browser using XBAPs however this is basically just downloads and runs the XPF (so your users need to have everything that WPF needs - Windows, .NET 3.0+ etc..)
Silverlight is a proper web technology - meaning it runs across browsers and OS.
So which can you use:
From Silverlight/WPF you can call to web services meaning you can easily reuse your business layers, although you just may need to wrap them.
I would not recommend a full change though - I would adopt a hybrid approach of using Silverlight + MVC. Swap out the parts of the front end (view) that make sense with Silverlight but keeping the the ASP.NET MVC code. This not only means your change is small (you can test out a single change and get feedback from users such as maybe your user base doesn't have permission to install Silverlight and thus can't use it), and you keep the ability to unit test a large part of your code still.
just wanted to clarify the options for client presentation :
1) winforms - for windows client - older technology
2) wpf - for windows client - newer technology, uses xaml
3) jquery - for web client - uses javascript
4) asp.net ajax - for web client - older technology
5) silverlight - for web client - newer technology, uses xaml
for the web client, what are the pros and cons of option 3, 4, 5. is it better to learn jquery or asp.net ajax ? is silverlight mature enough to be used ?
In terms of desktop applications, you cannot go past WPF, the problem is there doesn't seem to be a huge knowledge or push for commercial projects using WPF.
I have been using it to write my companies in house applications and it is miles ahead of winforms, it brings all the UI templating and reuse that asp.net can have to desktop apps, plus a whole lot more.
Spend some time to play with it, especially look at the binding side the using Linq and a project like CLinq or BindableLinq to propagate changes to the base lists to the UI without handling any events.
jQuery and ASP.NET Ajax complement each other so I guess it's not an either or for them, at least not according to Microsoft.
The problem with Silverlight is not maturity but rather the low rate of installations. In an intranet scenario this might not be a problem. Also Silverlight suffers from the same problems as Flash. It's harder to get linkability, searchability and such.
I'd like to add MVC, it's part of asp.net depending on who you ask but it's so different that it's worth being on it's own.
I recently rebuild an old asp.net webapplication in asp.net mvc for a customer and he was very impressed with how much more intuitive and fast the application had become. I did not do any functional changes. Just the presentation part was changed. I'd say it's worth mentioning here.
These 2 blog entries from ASP.Net answers my question
http://weblogs.asp.net/paullitwin/archive/2009/03/30/the-four-pillars-of-asp-net.aspx
http://weblogs.asp.net/shijuvarghese/archive/2008/07/09/asp-net-mvc-vs-asp-net-web-form.aspx
Is there any way to turn to WPF app into an ASP app? Or are they totally unrelated technologies? XAML format reminds me so much of HTML that it seems like there might be a way.
WPF app is a windows application while an ASP.Net app is a web application. These two platforms have huge differences which make it hard to convert. In most cases this isn't even feasible due to different limitations and strengths of these platforms.
For viewing this might be possible but if the WPF application does anything like write to the local filesystem or modify something on the user's computer this just won't work on the web.
If the application is for internal use, you could look into XAML Browser Applications (XBAP). These have only security limitations which you can bypass by signing the deployment and propagating the correct certificate to the client computers through the Domain. The great part about XBAPs is that they can share assemblies with the WPF application and so converting WPF application to an XBAP is quite trivial.
Silverlight is another possibility but there are quite major differences between WPF and Silverlight and turning a WPF application into a Silverlight application requires more rewriting than one might initially think. The Silverlight engine is built on top of .Net but it uses different virtual machine and isn't binary compatible. It's still easier to port to than to ASP.Net!
Even if you would manage to convert the XAML to ASP.Net HTML you'd have problems with the minor differences in control behaviours. And if your WPF app is using the major WPF features such as embedding controls inside tab page headers or applying transformations don't even think of trying this.
I don't believe there is an easy way to do so; they are indeed basically unrelated technologies. WPF renders to your screen while ASP.NET renders HTML for viewing through a browser, and all the event/data pipelines are completely different.
Though you could convert your WPF app somewhat easily into a Silverlight app if you want to run it on the web.