Webforms vs. Winforms decision

  • Thread starter Thread starter 3Cooks
  • Start date Start date
3

3Cooks

I have a windows application written in Visual Basic 6.0 that is going
to be redeveloped in dotNET. We are trying to decide if we should
deploy using Webforms or Winforms and I need advice from someone who is
not on my team.

The VB 6.0 application is used by approximately 100 users. All users
reside in-house. There is an existing external website that will use
some of the same components but the two applications are separate.

The VB 6.0 application is backed by SQL Server. Users view data,
update, delete data via the front end. The data is all real time.

We are considering using Webforms for a few reasons. The industry
seems to be headed towards web development. If the user's desktop
applications move to Webforms, we want our application to mimic the
applications they use most often. I am thinking of the Office Suite of
applications, Outlook, etc. I have been told by a colleague (who is
very biased) that Microsoft is going to move all of their desktop
applications to the web. Webforms are much easier to deploy than
Winforms (especially since we will be using VS 2003 not 2005. Our 2.0
framework won't be delivered to the web servers in time for VS 2005).

I have been told by another colleague that this is not a true statement
and that we should stay with Winforms. We would not have to manage
state if we used Winforms. We would probably have a richer UI,
although our application is not flashy (or Flashy).

The team is made up of mostly VB developers. We have a couple of people
who are web developers and one person with .NET experience. The rest
of us will be learning .NET.

Can anyone give me some advice or tell me how to base my decision?

I appreciate it very much.
 
Here is some info as objectively as I can give it:

- Web development takes much more time than windows developer. Managing
state, security, etc.. is a little harder in web applications... In all my
projects, web development takes longer. Very often I make comments to
myself like "I would not be doing this if this was a Windows application!".
There are a lot of little chores to take care of such as maintaining
viewstate as small as possible (so you need to do some tricks or extra
database lookups so as to keep page size (which includes the viewstate)
small, among other chores you have to do (sessions, etc...)

- Take care of the "showstoppers": Problems that, if not solved, would break
your application, before you actually write a single line of code. This
step is critical. For example, if your app will be used outside of your
office (which, admittedly, you did not state), then the fact that even
obfuscated .NET is relatively easy to decompile might prevent you from going
the WinForms route. If there is a certain look and feel that you want to
use throughout your app, make sure you are either willing to write your
controls, or there is a control library (ie, Infragistics, ComponentOne,
etc...) that you are willing to buy that provides the look and feel you
want. Make sure it is available for the platform (WinForms of WebForms) you
are leaning towards.

- The fact that "the industry seems headed towards [the WebForms']
direction" should not be construed as "the WebForms platform is as mature as
WinForms." Like I told you, there are more complex issues, more
housekeeping to do with webforms.

Here are some examples of things that take 5 minutes to do in WinForms that
take hours on WebForms:

o I had an Infragistics tree view control with checkboxes for each item that
I had to dynamically check and uncheck client-side depending on certain
conditions (ie, another checksbox was checked). I had to do it in
client-side JavaScript which has awful debugging support (more so in VS2003
than in VS2005), and it turns out I had to keep running the procedure over
and over again until I found what my problem was. It was a syntax error,
which caused IE to disregard the existence of my JavaScript function
(instead of telling me where my error was). This whole thing would have
taken at most 5 minutes on WinForms, and the syntax error would have been
caught at build time.

o If you want to prevent the user from pressing a button (and performing the
action) twice, you have to create a javascript function to disable the
button. This is not an issue with WinForms.

o Postbacks on web pages are awful. If you want to minimize them, then you
have to do client-side scripting via JavaScript plus also some AJAX....
This can get extremely complex, and there is certainly a learning curve to
this. In WinForms it is all built-in, no extra coding required.

I could really go on and on... But the truth of the matter is that it is
much easier to write a WinForms ap than it is to write a WebForms app.

Plus, also distributing installers is extremely easy with .NET. You do not
have all the DLL issues you do with VB6. Just create an installer project,
configure the shortcuts, icons, etc... and you are home free.
 
RE:
<< The industry seems to be headed towards web development >>
This is a bunch of baloney slices. At one time Web forms became *possible*
and then a bunch of people started creating Web applications. That doesn't
mean *the industry* is moving away from other application types. Say a new
Mexican food restaurant opens in town and they get a bunch of business. That
doesn't mean that the "town is moving towards Mexican food". Sheesh! You
could only say that if everybody also stopped going to all the other
restaurants in town.

There are .NET Mobile apps now as well. According to your local pundit's
logic, we'd expect "the industry" (whoever that is) seems to be "moving
towards mobile apps." It's just nonsensical to make such a statement.

The bottom line here is that there are many application types:
- Windows Forms
- Web Forms (ASP.NET Web Applications)
- Console Applications
- Windows Services
- ASP.NET Web Services (.asmx)
- COM+ Enterprise services (and other Remoting varieties)
- Mobile Client apps
- Smart Clients
- etc.
None of them are going away! They're all here for the duration. Your
decision on which to create should be made based on a good match between the
application type's capabilities and the needs of your organization. Period.

The argument about deployment is a non starter. With Click Once Deployment
(see http://tinyurl.com/8zjdd for more info) you can deploy full-fledged
Windows Forms applications about as easily as Web applications. Heck, even
before .NET and Click Once I rolled my own updator for a VB6 exe. 200+
clients would automatically update themselves simply because I'd put a new
exe on a central server... I even had a version that would deploy AND
register new COM DLLs on the client machines. All I had to do was place the
new or updated COM dll on a central server. So don't make your decision
based on deployment methodologies - especially when there is practically no
difference anyway!


RE:
<< I have been told by a colleague (who is very biased) that Microsoft is
going to move all of their desktop applications to the web. >>
You must work at that place in the Super Bowl add where the guy worked in an
office filled with monkeys.
I"m biased towards Microsoft as well, but come on... this stuff about moving
all desktop applications to the Web is complete and utter nonsense. What
does he literally mean by saying that anyway? Are they going to convert MS
Access to be an ASP.NET Web application? Come on! Now, if he's saying they
are going to make them deployable via the Web that's a totally different
thing and it's technically possible (although not likely).

RE:
<< I have been told by another colleague that this is not a true statement>>
You should listen to that person.

Also, consider that the learning curve on an ASP.NET Web application is
potentially VERY time-consuming. I've been doing non trivial ASP.NET Web
application development full-time+ for 3 years and I'm just now starting to
"get it".

Here's what you'll encounter on your learning curve Web Forms (ASP.NET Web )
Applications:

1. HTTP (3-way handshake, etc.)
2. The request/response model
3. state management
4. Client-side logic and scripting vs. Server-side.
5. HTML and CSS (content and layout vs. styling)
6. Browser variations and limitations
7. IIS (Web server; what role it plays and implementation decisions)

All developers involved in the project will need to have a good
understanding of at least all of these things in order to create and/or
support non trivial Web applications. You can see that there is much more
than just "state management." And no, all those templates and master pages
in 2.0 don't get you off the hook in any way. You still need to know all
these things.

RE:
<< Can anyone give me some advice or tell me how to base my decision? >>
Advice: Continue getting multiple opinions and then use your good ole'
common sense to weigh them. These NGs are a great place to get relatively
quick access to multiple good points of view (unbiased in the sense that the
responders aren't in your organization) Ask a good and specific question and
you'll likely get helpful responses.

And, once more...
Your decision on which to create should be made based on a good match
between the [application type's capabilities] and [the needs of your
organization].

Good Luck!

-S
 
Hi,
I have a windows application written in Visual Basic 6.0 that is going
to be redeveloped in dotNET. We are trying to decide if we should
deploy using Webforms or Winforms and I need advice from someone who is
not on my team.
Click to expand...

4 years ago (VS 2002) we had to make the same decision when redevelopiong a
big financial app.

Webforms was chosen by management, based on some good reasons (ease of
deployment, no installation on clients, can be used worldwide) and some bad
(webapps are hot, no more DLL-hell).

Nevertheless, at that time it seemed the best option (also to me), but
looking back we should have gone the Winforms route...

Why?

- Develoment time is significant higher. You need state-management. You need
need to know about HTML, CSS, JavaScript (possibly cross-brower) & IIS.
- Some parts of our app demand a lot of data-entry. Because most of the
field are related, this means postbacks. On every postback all data is send
back & forth, making it slow. We had to write a lot of JavaScript to
minimize this, but even then there are limits.
- Users *demand* the same user experience as desktop apps can give them,
meaning you will write a lot of JavaScript. This is a very time-consuming
task.
- You can't access resources on the client's PC (obviously).

This is just my opinion. I took the time to write this down because I feel
it might help you. Learn from the mistakes of others.

Steven
 
Hi 3Cooks:
Your name sounds interesting and your dilemma even more.My point is that you
should go with winforms as your application will be used inside your trust
environment so you can provide better responsiveness.Apart from these you can
use remoting also to make your application truely global.
My point is that whether you use winforms or webforms, design your
application in such a way that only view changes while changing interfaces.
But my point of concern is that winform skill is rare in industry.We be this
is result of web form hype.Please bear this into mind while making decision.
Bright side to this is that having rare skill in your toolbox improves your
job prospects when someone requires that skills.

Thanks,
Inayat
 
Back
Top