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.
Related
I am trying to migrate a project from classic ASP.Net Web Forms to ASP.NET MVC.
While I have read through http://www.codeproject.com/Articles/38778/ASP-NET-WebForms-and-ASP-NET-MVC-in-Harmony. I have a basic idea on how the code structure, libraries and routing should be done.
For your information, the scope of my existing project is around 400 pages and 300 tables.
On top of my head I have two approaches:
Start from stretch, rewriting the whole system - Obviously this would require intensive work and take a long time. Any change made on existing system would need a duplicate change made to the new system.
Migrate the page one each - I still have a rebuild the entire core library (for accessing db), and get the page migrated one by one. For this I would assume to have two core libraries (new and old) running simultaneously with different pages connect to one of those.
Would anyone have similar experience and advise a proper way to start?
For this complete revamp I may also target at the latest technology - .NET Core and MVC6, by taking these would I have extra advantage, or some blockages I would have to take care of?
Any suggestion and opinions are appreciated. Cheers.
Microsoft is a bit hush hush on the subject but the WebForms engine is probably never going to make its way to ASP.NET Core. One might think that MS is waiting to see if the community is calling for a port, but I think they're trying to kill it discretely (not like Silverlight).
Why? Because it proved to be a bad good idea on the long run, easy to use at first, but extremely complex to master (because of viewstate and page lifecycle), with a tendency to allow average developers to build very tedious application (in french we say steam factories). Also it was very poorly adapted to modern web development (Ajax, unit testing, IoC). They tried to fix it with a couple of tweaks, but the overall architecture is just not adapted to this kind of things. MVC is a treat in comparison!
To answer your question, it's not really possible to migrate WebForms to MVC, because those are quite different architectures, and of course the architecture is what an application sits on top on, so if you change it, you might as well rewrite it from scratch.
What can help you a lot is if your app is divided in tiers (business, data access, UI). If it's not the case, you could start by doing this, properly separating the UI project from the rest. Then you would just have to rewrite the ASP.NET project and not the rest.
There are some useful resources I'd like to share with the StackOverflow community just in case you are having troubles to decide what to do:
modernization of your existing Web Forms app
migration to MVC or Core
or whether to start a new project on Web Forms, MVC and Core.
Here you go:
https://www.telerik.com/blogs/review-of-telerik-toolsets-for-aspnet-web-forms-core
Modernizing ASP.NET Web Forms Applications by Tomáš Herceg (Microsoft MVP ) - https://tomasherceg.com/blog/post/modernizing-asp-net-web-forms-applications-part-1
Migrating Old ASP.NET Applications to .NET Core by Edi Wang (Microsoft MVP) - https://edi.wang/post/2018/10/31/migrating-old-aspnet-applications-to-net-core
Choose between ASP.NET and ASP.NET Core (Microsoft docs) - https://learn.microsoft.com/en-us/aspnet/core/fundamentals/choose-aspnet-framework?view=aspnetcore-3.1
Migrate from ASP.NET to ASP.NET Core (Microsoft docs) - https://learn.microsoft.com/en-us/aspnet/core/migration/proper-to-2x/?view=aspnetcore-3.1
i have come across below links
https://www.youtube.com/watch?v=CZuqMrWSano
https://www.dotvvm.com/blog/59/Modernizing-ASP-NET-Web-Forms-applications-with-DotVVM
DotVVM package helps us to migrate ASP.Net Web Forms migration to ASP.NET Core without re-writting completely.
i have not tried any production application. still have tried some sample pages. you can try this out.
I can agree that for many cases a re-write of an ASP.NET application where WebForms is used widely may do not provide any business value.
Therefore we decided to use our experience with ASP NET WebForms to develop a highly compatible port of WebForms for ASP NET Core / .NET 6.0.
We use the solution in our own ASP NET WebForms-based products and projects as well as a licensable component library.
So the Forms can still be used and you can focus on the .NET CORE/6 migration.
I am supporting an ASP.NET app, which is installed on a web server and a VB6 app installed on a different app server. There is code duplication in the VB6 app and the ASP.NET app. I want to use some of the code in the ASP.NET app in VB6. I believe I have three options:
Expose the required functionality in an ASP.NET web service. The VB6 app will consume the web service.
Rewrite a small section of the vb6 app in .NET and extend the asp.net app. This will eliminate some of the code duplication.
Setup a class library for the ASP.NET app. Install the vb6 app on the web server. Expose the required functionality from the class library in a type library.
Which option is best? I believe option 2 is best.
Option 1. That leaves your shared, already-tested code on the most modern platform.
This is very hard to answer, as it varies for each company and each situation.
As a general rule, I'm very much in favor of using web services where possible, especially if multiple applications are using the same logic for the following reasons:
If I have to change the logic, I can do it in one place and fix all apps that depend on it
The same can be said for database connection strings, etc.
A bug fix can also often be fixed in one place.
I've had difficulties with a particular database that I need to deal with, where the vendor's updates tend to break their .NET adapter. Twice I had to modify/recompile a ton of apps to resolve this. Since then, we made it a policy to connect to that DB only via web services, so I'll only need to update one app in the future.
When developing mobile apps, the simple fact that we already had all our code in web services makes it that much easier to write apps that are strictly UI and leaving the business/database access logic as-is in existing web services.
All of those are pretty much "Standard" arguments for the SOA approach.
All things considered, my first recommendation, not knowing your specifics would be option #1.
There is a fourth option - a total rewrite of the VB6 app, if it's feasible, and if you can convince those who control the budgets and time allotment. Even with that, you can use the Service Oriented Architecture and split much of the logic into web services.
Are there any good books or websites on this subject covering subjects like:
different migration scenario's (big bang, module for module, function for function) pros and cons
do's en dont's
tooling
handling customer expectations
We have a rather large winforms based product which we would like to migrate to the web. Migrating in a 'big bang' scenario would probably take at least two years. We're looking for alternative scenario's.
I'm especially looking for ways to handle the inbetween scenario, what options do you have to keep customers happy.
Let them use the windows application at the same time as the new web
application?
Let the windows application use the new features from the web
application via a service interface?
Accept the cost of double maitenance for a while to keep customers happy?
You are more likely be doing a complete rewrite. Because web is conceptually different from windows forms, there would be a lot of changes.
Your best bet is stop new development on windows forms app. Start writing a new app for the new features. Then start moving one isolated feature at a time to web.
You have two options for the UI
webforms - matches closely with windows forms model. If you are
using any 3rd party controls like devexpress, you can find the
equivalents in webforms.
mvc - It is more like re-architecting the whole presentation layer.
If your UI layer is already separated from business layer, then it
would be a good choice to go down the path of MVC. However the
development experience is totally different from doing windows
forms.
State
Maintaining application state is comparatively simple in windows
forms. In webforms you have viewstate to do that for you. But you are going to run in to rude shocks as you run into limitations of viewstate, especially when it gets too large.
In MVC, you are completely responsible for maintaining the state.
New skills
You require new skills to mimic state-full scenarios
Strong understanding of javascript, ajax, at least one javascript
framework like jquery. 3rd party commercial tool kits can ease some
of these pains.
Depending on complexity you might need web application frameworks
like Backbone.js /Knockout
Expectations
It would be very expensive to achieve the same responsiveness as windows app, as you will be messing with multiple technologies. Probably your users are going to hate the new app initially. Having skilled web designers on staff is very important
Based on our own experience with moving applications from desktop to web: carefuly inspect the architecture of your winforms applications and if possible - try to provide a web interface at the service or persistence level so that your windows applications use web services instead of directly talking to the database. Then you can let your users launch desktop modules from the application server using clickonce.
Such approach let us move to web quickly and users got the same GUI and a new way to access the application. In fact, it took like 3 or 4 months to redesign existing applications so that they use web services.
Then, we were replacing modules one by one, implementing them as web applications and maintaining both (clickonce and web) for a short period of time so that users were able to get used to new modules.
The migration of consecutive modules from clickonce to web was prioritized in an obvious way - we've started from modules that were used by most users. In fact, the initial release of the system has only one web forms module ready and remaining modules are being replaced for over 2 years now, one by one.
I am starting a new project which will need a ASP.NET MVC 2.0 website, a Silverlight section and a Windows Phone 7 UI.
My plan was to use WCF RIA Services to create a set of services which would be used in all different UI projects. With the Silverlight project I would use the standard tool integration, the Windows Phone looks like it may have to be WCF Services exposed by the RIA Domain Services, but I'm not sure about the ASP.NET MVC website.
My initial thoughts I would simple reference the class library containing the Domain Services and use them directly. Could this be considered a viable approach to using RIA Domain Services in a ASP.NET MVC website?
Kind Regards
Michael
I know a long time has passed since this question was asked, but since I had to make such a decision, I might as well document it for the benefit of others.
I work in an environment where lots of legacy and new apps co-exist, with the legacy apps being phased out. So we've had to build interoperability between everything from MS Access, to web service end points in C#, VB, Web Forms, MVC 3, even Flex, Reporting Services...the list goes on.
One of the biggest pain points in a multiple-client scenario is the maintenance of interoperability over time. As data, requirements and delivery mechanisms change, keeping things smooth ends up taking a lot of resources.
My approach has been to create one and only one mechanism for reading a given source of data by defining 1) a model, 2) a serialization/deserialization layer and 3) a service layer. All projects that need to use XY_Data must use the XY_Service to get XY_Objects via the XY_Serializer. Direct db calls or stored procs, etc are allowed in the XY_Application. This allows me to drop in replacement DLLs (versioned) with bug fixes and upgrades without restarting anything. I hardly ever do a full publish.
So yes, what you're suggesting will work. I would recommend only that you rigorously enforce the single-source-of-truth and DRY policies both in your data and your APIs.
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.