I am trying to evaluate whether we should migrate from developing our product in ASP.net web forms (current technology) to Silverlight. I remember reading that silverlight development can add to development speed, so this is the main driver for me to think about this.
I am assuming that business logic development will take same amount of time, I am open to it if UI development speed will bring in significant benefits.
The App we have is a line of business data driven app. There are very few rich reports required, however the printable data reports need a lot of formatting (since the app is highly configurable in terms of data setup; for eg which columns have a merged header and then sub headers, which cells to show data in red, etc). Apart from this most of the UI is Asp.net webfrms for entering data.
Do you see any significant improvement we can achieve by moving to silverlight? We also need to consider time to migrate existing UI and the learning curve, but if that were not a constraint, what would be your view?
I could see you gaining a lot using Silverlight, especially with the awesome charting controls that are available. This is compounded with how easy RIA services makes creating data driven applications. That said, it really depends on your development team. If they are already familiar with Silverlight I would go for it, but if they are not be wary that initially it may be slower than if you were working with ASP.Net.
It's not an either or situation. You can use a Silverlight app from within your ASP.NET webForms app. So you could develop some functionality using Silverlight while leveraging your existing codebase and effort.
The two work hand in hand.
Related
A little Background:
I started my career almost 5year ago as a web developer using ASP.net and C#, after working as a web developer for only a year i switched to the world of low level programming (i.e C/C++).
Now, from last 4 years i have been working in c/c++
At present i have been assigned a task to develop a large scale web application (by large scale i mean large number of users probably in million and huge communication among those user like communication at twitter or facebook and obviously a huge backend database aswell).
Since i worked in ASP and C#, so i will prefer to develop this application using ASP.net and C#
My Question:
Currently the project is in requirement gathering phase and in the meanwhile i am assigned a task to design its architecture. Now i google various architecture resources and came across following:
MVP
MVC
Three Tire Architecture (One which i use 5 year back)
Please mention some more, if there exist coz i only find those 3
Now i am totally confused with first two because some site mention that if i use MVC then i am not allowed to use WEb forms, and many more . . .
Secondly some sites also mention SOAP and REST but i feel that i am not able to use with ASP.net and C# (with the .Net Framwork 4.0)
What i Want
First, i appologise in advance coz i feel this all confusion arise because i have experience in C/C++ rather than web development.
Secondly, i know that no one did the job done for me and even i don't want to do so, i only need good guidence i.e where to start with, what resources should i study etc.
This site is build on MVC.
MVP is more suitable for older ASP.NET technology like WebForms, but can be a pain.
Three Tier Architecture is more a overall system architecture where you have a database, service exposing database, and consumers using the database. Sometimes it also refers when you separate your app in three layers, like data, business and presentation. MVC and MVP are just UI patterns.
Now, you want someone to tell you what to use, which is impossible, because we have only tiny piece of picture. However, I would always prefers MVC and heavily object-oriented practices when designing the application, except when something to be put fast is to be made.
The Internet is full on tutorials on all these technologies, you should familiarize yourself first with them, and then decide which one to use.
I'd like some vague guidelines about the relative effort to build using ASP.NET versus Silverlight/WPF. I know, it all depends, but any input greatly appreciated.
I'm rebuilding a winforms app and planning on moving it to either:
ASP.NET (could be MVC or webforms), or
Silverlight (4) or WPF with ClickOnce deployment.
It's a typical business-style app with some tens of forms, various datagrids, standard windows controls, etc. Some chart graphics but no multimedia. It's not very data-heavy, i.e. there are quite a few datagrids but they'd seldom have more than 10 cols & 100 rows and usually less. The logic is currently tightly coupled with the winforms code so either way it'll need to be split out from the UI. We also use Crystal Reports for reporting.
The 2-3 developers who will be working on this have some WPF & ASP.NET experience but not much.
I'm tempted to use Telerik controls or similar as they look like they make some things we want to do easier.
The app is installed for a customer and only used internally within their firewall. The main advantage to ASP.NET would be deployment, but I figure that silverlight or wpf with clickonce wouldn't be much worse for deployment and may be faster to build.
If there's any other general information I can provide which will make it easier to estimate relative effort, let me know!
thanks.
UPDATE:
Let's assume the only basis for my decision is the speed/productivity of development (i.e. ignore deployment, UI impact, etc). Which should I choose?
What you use and how cost effective the project will be totally depends on requirements and your team's skill sets. Learning ASP.NET (MVC or WebForms) is typically a long, hard road if you come from a WinForms background (and arguably, if you are doing WebForms, you may as well so Silverlight). If you have a lot of experience with HTML/CSS/JavaScript(jQuery)/MVC patterns, then ASP.NET MVC will probably suit your project better. If you have requirements such as cross-browser compatability, SEO or other weby things, you'll probably go ASP.NET MVC.
On a recent project, where we had an assessment of the requirements and available technology options, we were forced down the ASP.NET MVC by the client but we had determined that given the team and requirements, Silverlight would have been an easier (read: less expensive) technology to implement the application in and it would have reduced the project cost by 50%. (educated, thumb in air guess)
In my experience, the biggest delays are caused by "black holes" - things that you'd assumed were going to be easy when you put together your estimates, which turn out to be hard/complicated/time-consuming due to leaky abstractions, framework bugs, and so on.
I'd therefore favour an approach which uses proven technology and protocols and minimal abstraction, and for me, that would be ASP.NET MVC. But make sure your developers understand HTTP, HTML, the model-view-controller pattern and the fundamentals of stateless architecture.
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 8 years ago.
Improve this question
Our team is divided on this and I wanted to get some third-party opinions.
We are building an application and cannot decide if we want to use .Net WPF Desktop Application with a WCF server, or ASP.Net web app using jQuery. I thought I'd ask the question here, with some specs, and see what the pros/cons of using either side would be. I have my own favorite and feel I am biased.
Ideally we want to build the initial release of the software as fast as we can, then slow down and take time to build in the additional features/components we want later on. Above all we want the software to be fast. Users go through records all day long and delays in loading records or refreshing screens kills their productivity.
Application Details:
I'm estimating around 100 different screens for initial version, with plans for a lot of additional screens being added on later after the initial release.
We are looking to use two-way communication for reminder and event systems
Currently has to support around 100 users, although we've been told to allow for growth up to 500 users
We have multiple locations
Items to consider (maybe not initially in some cases but in future releases):
Room for additional components to be added after initial release (there are a lot of of these... perhaps work here than the initial application)
Keyboard navigation
Performance is a must
Production Speed to initial version
Low maintenance overhead
Future support
Softphone/Scanner integration
Our Developers:
We have 1 programmer who has been learning WPF the past few months and was the one who suggested we use WPF for this.
We have a 2nd programmer who is familiar with ASP.Net and who may help with the project in the future, although he will not be working on it much up until the initial release since his time is spent maintaining our current software.
There is me, who has worked with both and am comfortable in either
We have an outside company doing the project management, and they are an ASP.Net company.
We plan on hiring 1-2 others, however we need to know what direction we are going in first
Environment:
General users are on Windows 2003 server with Terminal Services. They connect using WYSE thin-clients over an RDP connection. Admin staff has their own PCs with XP or higher. Users are allowed to specify their own resolution although they are limited to using IE as the web browser.
Other locations connects to our network over a MPLS connection
Based on that, what would you choose and why?
I am especially interested in hearing from developers who have experience with both ASP.Net and WPf.
Reasons to choose WPF:
Much faster and easier development than ASP.NET and jQuery
Much easier to implement quick incremental background loading of data
Much easier to implement client-side caching of commonly used data (important for remote offices)
More efficient data transfer from server (can use advanced WCF features unavailable to web browser)
Keyboard navigation better, since you can easily define shortcuts, etc, and not be limited by browser
Maintenance overhead much better using MVVM pattern
Softphone integration easy
Reasons to choose ASP.NET and jQuery:
None that I can see
In your scenario I would definitely choose WPF.
First of all, I would sit down and write the business requirements and specifications. It really doesn't matter what tech you use - proper planning will affect your project timeline more than technology choice. This is especially true for an in-house custom built app.
As far as development, I would take the requirements and lay out the backend functionality. I would actually implement the backend in WCF, regardless of the client technology - that way you could use best of both worlds if needed (for example for phone integration you could write a stand-alone WPF app). ASP.NET with jQuery can easily use WCF services (JSON or XML version) together with desktop client.
As far as development of the client forms, this highly depends on developers experience and your future plans. I am not going to go into advantages/disadvantages of developing web software here - there are a ton of articles in the last 10 years about cloud/web based software (for example salesforce). I would rather concentrate on deliverables - what is your team most comfortable with today and in the future. There's a huge difference between WPF and web development, from development standpoint, and it requires completely different experience.
Why not consider a hybrid solution - Silverlight
With Silverlight you get most of the goodness and statefullness of WPF (with almost exactly the same XAML and code), plus you get the deployment characteristics of ASP.NET
Many people consider Silverlight the next step after ASP.NET/AJAX, and it would definitely deliver all of the benefits of WPF relevant to your scenario.
WPF is the way to go, without a doubt. I agree with all that #Ray Burns has said.
Because:
You will get a richer, slicker, faster application.
It will be easier to build1.
Softphone/Scanner (i.e. hardware) integration is going to require browser plugins etc. and this can be a nightmare with a browser based application.
Keyboard navigation is still better with native applications.
IME Maintenance is easier with WPF applications.
Definitely use WCF to provide the backend via The Entity Framework, see The Entity Framework In Layered Architectures. You can do have a better integration with the backend in a native application because it can be called inline - no need for callbacks or ajax. I've built components for WPF that are linked via EF to the business logic to provide aware controls for simple stuff like validation. It's stunningly good to drop a customer name field onto a form and it just works.
To add additional components you need to build it with a proper well thought out plugin architecture. This is the same in both environments. I've got some thoughts on this I jotted down in my journal entitled Designing a plugin architecture for an application
When building a WPF application you will be writing in one language (e.g. C#) + markup (XAML). When building asp.net you endup with two languages + markup, as you always have to code some Javascript.
So, based on your requirements it has be to WPF / WCF (EF). A web based application will be a lot more work, more complexity, and not be as nice.
About 12 months ago I was fortunate enough to be given a free hand to choose the technology for a new application. I spent almost a month evaluating all of the options and came to the conclusion that it had to be C#, WPF, Entity Framework. After writing the application I can confirm that it was the right choice...
1. It will still be easier even if your programmers have to learn WPF first. WPF is much better thought out, great and lovely. very lovely. It just works right.
Hi
I think The question at issue is Windows-application or Web application(WPF for win-app VS asp for web-app), Which one is better for you and your project?. In this case your platform is network and your program must work on the net. so for this usage Web-app is better but there are a lot points existing which can make decisions hard. Network platform has great challenge.(according to my personal experience)
Working with web-app by asp.net is nearly hard. you must try to handle many thing's for web-app(request time, session management, even poor UI in comparison to WPF, j-query, etc ). Remember this is not as easy as simple web site.
But win-app is good for network with this condition: "local network"(mpls is almost the same). Absolutely developing win-app is easier than web-app ("At least number of users expert in net-program developing"). for this case WPF has many good things(UI , command, etc) also has many challenging point(like multi-threading and lack of expert developer in this field ) . I'm rather with wpf than asp but decisions is yours
And chalk point to good thing Silverlight but if you want to use this you must look at prism framework : http://compositewpf.codeplex.com/
I have recently developed a project separately with asp and silverlight(prism framework). developing silver-light version is too hard and takes more time than asp.net version but at the end SL-ver have great look nothing else!
Burns pointed to good issues about wpf. also consider Artemiy's post. your environment conditions is same for both of them. WPF/ASP can work with scanner and soft-phone cuz the base of both is on C# and .net library
Finally what ever your decisions is you must hire advance developer at least develop one business-app for the network platform.
Is your app a desktop app or web app.
If Desktop wpf is best.
If web based asp.net is best.
Don't front load your development with your get it up quick scenario. That never works well and results in a sloppy deployment. Take your time, cover all the steps (Business Requirements, System Design, Program Design, Code, TEST and TEST some more, Deployment)
Some points to be made for ASP.NET:
The pool of ASP.NET developers is much larger then the pool of WPF developers.
Which means you can probably find qualified ASP.NET developers easier.
ASP.NET is probably more future proof, chances of WPF getting large changes and being hard to port to later versions is probably larger.
Also keep in mind that the focus of MS seems to be on Silverlight so there might be a consolidation down the road which makes WPF obsolete.
More mature eco system of ASP.NET makes for more out of the box solutions to use to solve problems.
With multiple locations you might be able to skip a few layers and go directly to a website?
I am on a project helping to analyze the load a VB.Net WinForms application can take. This app has been in production for several years and has many many products on it. We plan to add more products but see the client footprint rapidly increasing. This is contributing the degradation of performance on the system overall.
There is duscussion that moving the UI intensive portions of the app to ASP.Net it will reduce the client footprint and solve many of our issues.
My question which of the following will scale better in terms of performance and load?
- ASP.Net(VB) Web based architecture
- VB.NEt WinForms 3-tier architecture
Links to articles on the topic are also appreciated.
Additional Info
Client - Apparent issue is large memory footprint due to data caching (High cph utilization)
Middle Tier - web services that house BLC & DALC assemblies (Low utilization here)
Database - Multiple database that that serve data to the DALC via sprocs (Medium Utilization)
Deployment is not an issue, we have a very well developent methodology there.
Thanks in advance,
Freeon
Winforms will scale better than ASP.NET
B/c
a. when you use an ASP.NET client - (a Browser) you pay a price, html rendering - another price, Viewstate - a huge price.
about view state - it is a chunk of data that might grow more and more as long as you operate even on the same page.
You need to use special techniques in order to make a asp.net webform efficient (AJAX).
You don't have this on winform.
Anyway - a specific answer should be aware of your product functionality, architecture and design, so this is gust a general advice.
Not enough data...
In terms of a user interface a desktop application should out perform (by various measures) a web based one in all but the most trivial of cases - that's not to say that you can't produce a very decent and capable web application but even then Outlook Web Access is not Outlook on the desktop.
To further illustrate the point, look at the effort going into Silverlight and Adobe AIR which are attempts to provide desktop level capabilites with web level deployment.
So the question becomes one of asking what is it in the current desktop application that is causing the problem i.e. is it a deployment issue, a performance issue or something else?
If its deployment issue then that will suggest one set of solutions, if its a performance issue then things get a lot more interesting.
Either way, there is insufficient data to do anything other than generalise enthusiastically
With a web based application you can scale servers both up and out for both the web server itself and the database servers. I would think that a desktop based application would be somewhat limited in how much scaling can be done, along with the need to update each and every client installation when changes/bug fixes are done.
There are negatives about web based applications. They will live in a stateless enviroment, the UI maybe somewhat slower than a desktop installation. It is possible to create UI's that are very responsive using lots of Ajax/Javascript, but the development time for those RIA needs may be more than desktop development. Connectivity issues maybe be of a concern, along with user browsers and such.
Quick deployment though of updates is one huge benefit of a web based application. You only have to manage one installation rather than many.
Good luck with your project!
I watched a little introduction into ASP.NET Dynamic Data, and I noticed this option to create a data driven website for the first time. I have a database with a few tables, just created a Dynamic Data application out of my database and well... my application with a lot of nicely looking web pages, navigation between them and all kinds of CRUD operations was finished after 3 minutes.
OK, seriously, it isn't finished of course. There is a lot of custom logic to introduce, design to change, and also pages or relationships to remove I don't want actually to see in the web application.
But now I am wondering if ASP.NET Dynamic Data is at least a viable starting point or do I better start from scratch and create page by page? I could imagine that it might be useful to create a quick database maintenance web interface but is it good for a very customized web application? Is it in the end more complicated to modify the scaffold than building up everything from the ground?
I'm very interested in your experiences or recommendations regarding Dynamic Data! Thanks in advance!
I could never wrap my ahead around it enough to get any use out of it. At first, I thought this was Microsoft's answer to Ruby on Rails, and I was looking for the same benefit. I don't it comes close to having the same benefits. When I then compare it to a CMS (DotNetNuke, Sharepoint, Drupal, etc) it then looks really underpowered. Compared to ASP.NET MVC, it seems like going the wrong way from basic ASP.NET (MVC is removing bad abstractions from ASP.NET, while DD is adding even more abstractions).
Personally I'd rather build something from scratch in ASP.NET MVC, though my day job is regular ASP.NET. I'm also learning Drupal as I haven't found the sweet spot with ASP.NET based CMSes. One thing at at a jobsite you're going to want to use technologies everyone else knows. So I think that limits where knowing Dynamic Data is generally useful, as basically any legacy application won't be using it and you're unlikely to find a team with existing ASP.NET Dynamic Data experience.
The quick scaffolding is spiffy but at the end of the day I don't think it will make web development easier.
I very like ASP.NET Dynamic Data as it is a fast way for creating data driven applications. Customization is not a complicated task.
I wrote a corporate website with this technology from the scratch - it takes appr. 2 months for all. So my point of view that this is a good starting point for web applications development.
if your archetecture resembles ASP.NET Dynamic Data or DotNetNuke or some other starter kit, go for it, if
application is small to medium sized
you do not have strict deadlines
you are learning the technology.
otherwise or when you will be skilled in particular technology, you will prefer yourself working from scratch as it gives you more freedom and space for the implementation of ideas.
For e.g, one reason for the breakthrough for Asp.Net MVC had was many .Net developers wanted freedom over the development / architecture / flow and rendering (HTML) of the product they were building. Asp.Net WebForms does provide solid and vast grounds for swift development and templates but developers had to go according to the architecture. This freedom is available under MVC and developers can make use of nearly all Libraries and skill set available and go their own way.
one successful sample is Stackoverflow.com itself
hope this helps