winforms vs webforms

  • Thread starter Thread starter brian.wilson4
  • Start date Start date
B

brian.wilson4

Our group is currently comparing winforms vs webforms.....app is Corp
LAN based - we have control of desktops.....Below is pros and cons list
we have come up with - if anything strikes you as untrue or you would
like to add - please comment - thanks.....

Rich Client PROS
1. User experience (* indicates feasible on web with AJAX) -
a. Single, unified application experience
b. Windows/Office-like look and feel -
i.Tabs - drag and drop tabs; open/close/minimize tabs*
ii.Common toolbar/menu options (ex. File, Edit, View)
iii.DataGrids - Excel-like look and feel*
iv.Split Container - split up screen into multiple
windows with separate controls in each window*
v.Panel Controls - like Outlook left panel (mail,
calendar, tasks, etc)
vi.Drag/Drop - easy in rich client; user could drag
files from one place to drop in another like in Windows Explorer*
vii.Parent/child windows - clearer in rich client; in
web would popup another instance of IE, in rich client,
pops up within the application
viii. Progress/status bars - allows user to see that
something is happening and how much progress has been made; can also
allow user to cancel long running queries, etc.*
c. Mouse/keyboard events - more events to access, keystrokes more
available (ex. Right click gives application options,
not just browser options)
d. Multi-threaded processing - processes run in background while
user continues to move through UI to other tasks
e. Seamless integration with MS Office
2. Logical transactions more easily managed in application vs. web page
-
a. Only one user, one connection; no need to manage connection
pooling
b. Two tier environment with business logic maintained in database
3. Simplified development environment -
a.No need for multiple development tools/languages (ex. CSS, AJAX,
javascript, dhtml, xml, etc.)
b.No application server coding needed; application and database do
all work required, no server intermediary
4. Simplified production environment -
a.Fewer moving parts; just application and database directly
connected; no web or application servers to maintain, upgrade,
provide DR for, etc.

Rich Client CONS
1. Availability of experienced winforms developers
2. Not part of current ASP.NET environment (although it is part of .NET
framework)
3. Strictly a LAN/intranet application
4. New releases require few minutes of update time on subsequent
opening of app
(terminal server only hit 1 time)



Web App PROS
1. Ease of deployment -
a. No downloads, no waiting for updates, no need for .NET framework
on client
b. Well established design/architecture patterns
2. Familiar interface; users are familiar with web-based applications
3. Leverage look and feel of other RECM ASP.NET applications
4. Ready availability of ASP.NET developers, books, articles, code,
etc.
5. Easier to move to internet in the future, if necessary
6. Security -
a. No code/business logic stored on client pc
b. No data stored on client pc

Web App CONS
1. Complexity of development environment -
a. Use of multiple development tools (ex. CSS, dhtml, xml, AJAX,
javascript, etc.)
b. While use of tools like AJAX allows for creation of more rich
interface, takes more code and experience to implement successfully on
the web than in winforms
c. Multi-tier environment requires more code to manage and deploy
2. Complexity of deployment environment -
a. More moving parts - web server, application server, database
server
b. Management of connection threads more complicated; connection
made to application server and to database server, so more expensive in
terms of memory and processing power
3. User Experience -
a. No multi-threaded processing; once user clicks "go" they are
stuck waiting for the process to finish before they can proceed
(possibly mitigated with AJAX solution)
b. Outlook/Office look and feel/functionality missing; more
difficult to integrate with desktop applications (like Office)
 
Brian,

Inline my comments if there is.
Rich Client PROS
1. User experience (* indicates feasible on web with AJAX) -
a. Single, unified application experience
b. Windows/Office-like look and feel -
i.Tabs - drag and drop tabs; open/close/minimize tabs*
ii.Common toolbar/menu options (ex. File, Edit, View)
iii.DataGrids - Excel-like look and feel*
iv.Split Container - split up screen into multiple
windows with separate controls in each window*
v.Panel Controls - like Outlook left panel (mail,
calendar, tasks, etc)
vi.Drag/Drop - easy in rich client; user could drag
files from one place to drop in another like in Windows Explorer*
vii.Parent/child windows - clearer in rich client; in
web would popup another instance of IE, in rich client,
pops up within the application

Is in fact in a webpage using ASPNET is a popup form not possible. The popup
is even very restricted by the latest windows OS software. (There is a very
old dialogbox however not any more from this time)
viii. Progress/status bars - allows user to see that
something is happening and how much progress has been made; can also
allow user to cancel long running queries, etc.*
c. Mouse/keyboard events - more events to access, keystrokes more
available (ex. Right click gives application options,
not just browser options)

Not true with ASPNET, for allmost all ASPNET controls are events. With the
exception of the mouse although for that delivers ASPNET more and more
javascript to the User Interface (the webbrowser). As example the new
menustrip.
d. Multi-threaded processing - processes run in background while
user continues to move through UI to other tasks

Windows is a multiprocessing OS. Don't over estimate the role of threading.
That is only possible in not serial processes. Optimistic multithreading is
still far out the scope of the microprocessor.
e. Seamless integration with MS Office

What is seamless, but far much easier than with a webform
2. Logical transactions more easily managed in application vs. web page
-
a. Only one user, one connection; no need to manage connection
pooling

This is no aspect in my idea, you do not manage them in both situations,
just do it correct and it is managed.
b. Two tier environment with business logic maintained in database

In fact is a ASPNET application a true three tier application. The browser
with the from the server gotten user interfaces is tier one. The
ServerApplicating acting in a thread per user is tier two. The DataBase
server is tier three.
3. Simplified development environment -
a.No need for multiple development tools/languages (ex. CSS, AJAX,
javascript, dhtml, xml, etc.)

At least do you need SQL transaction language. The same is however with a
ASPNET as well).

In ASPNET is dhtml seldom used, while xml is not really a tool/language but
a description of data, it can be used in both situations. Ajax is in fact
not used in ASPNET. Therefore is Atlas, which is in fact than no other
toolkit than a kit with controls like the others.
b.No application server coding needed; application and database do
all work required, no server intermediary

This is a statement thin as good silk. The database server and the IIS +
ASPNET can be on the same server. If it is about single user stand alone
applications, than there cannot even be a discussion if that should be done
in a Webapplication in my idea.
4. Simplified production environment -
a.Fewer moving parts; just application and database directly
connected; no web or application servers to maintain, upgrade,
provide DR for, etc.

See my previous statement.
Rich Client CONS
1. Availability of experienced winforms developers

This is not accoording your previous PRO's
2. Not part of current ASP.NET environment (although it is part of .NET
framework)

What do you mean by that.
3. Strictly a LAN/intranet application.

I would not say so a SQL Server works perfectly over internet. While with a
Webservice even an Jet (access) database could be used. (For the last it is
a fool who uses a Jet engine for that)
4. New releases require few minutes of update time on subsequent
opening of app
(terminal server only hit 1 time)

If you see this newsgroups than uses new releases on Terminal services
endless time (or beter experts). This because of the fact Net applications
(and more newer applications) have a more dynamic memory management than Dos
applications for what it is/was a great tool.
Web App PROS
1. Ease of deployment -
a. No downloads, no waiting for updates, no need for .NET framework
on client
b. Well established design/architecture patterns

What do you mean with b. I never saw that.
2. Familiar interface; users are familiar with web-based applications

Not so true, winforms applications are really become standardised. In
webforms you see all kind of menu's and behaviour by enter. By instance
dates and times are not yet globalized, therefore if the application is
outside an area you have to tell the format patern of the date. (By instance
Canada is using two paterns). This is than only the top of the iceberg.
3. Leverage look and feel of other RECM ASP.NET applications
???

4. Ready availability of ASP.NET developers, books, articles, code,
etc.

But far less than windowforms. ASPNET 1.x is almost completely different
from ASPNET 2.0. Although that the way of 1.x can be used.
5. Easier to move to internet in the future, if necessary

Why? See my earlier note about SQLServer.
6. Security -
a. No code/business logic stored on client pc

But needed is a very good security officer that is checking all the time if
all connections to the server are secure.
b. No data stored on client pc

That is not needed needed by winforms as well.
Web App CONS
1. Complexity of development environment -
a. Use of multiple development tools (ex. CSS, dhtml, xml, AJAX,
javascript, etc.)
See my note by winforms
b. While use of tools like AJAX allows for creation of more rich
interface, takes more code and experience to implement successfully on
the web than in winforms

Ajax is not giving a more rich interface it helps to make the interaction
time between client and server shorter because it is acting Assynchroon (see
it a little bit as what you wrote about multitier).
c. Multi-tier environment requires more code to manage and deploy

Depends on what you understand from Multi Tier environment.
http://en.wikipedia.org/wiki/Multi-tier_architecture

This is not so efficient to use with .Net

Others call a multilayer application as well a multi-tier architecture,
which is only the way your application is build and very efficient to do.
2. Complexity of deployment environment -
a. More moving parts - web server, application server, database
server

See my note by windowforms
b. Management of connection threads more complicated; connection
made to application server and to database server, so more expensive in
terms of memory and processing power

Complicated is not true, memory management and processing power of the
server is true, however the clients can mostly be as old as methusalem, I do
not see that at your pro's
3. User Experience -
a. No multi-threaded processing; once user clicks "go" they are
stuck waiting for the process to finish before they can proceed
(possibly mitigated with AJAX solution)

As it is in fact with windowsforms as well. .

b. Outlook/Office look and feel/functionality missing; more
difficult to integrate with desktop applications (like Office)

I think that there is much more, however you have written partially very
much about details and in the other way partially more global that I don't
think that I am able to add to this.

Of course is this just my opinion. Where other probably have others.

Cor
 
Hi Brian,

Can you be more specific about the environment in which these apps will run?
What exactly do you mean by "we have control of desktops?" Is this a
client/server application? Does it connect to a database? Is it in a LAN
behind a firewall? If so, would the LAN possibly be accessed via VPN
(Virtual Private Networking)? If so, what VPN product will be used? Is it
for Intranet or Internet use? What are the security considerations? All of
these questions help to determine the best solution to use.

--
HTH,

Kevin Spencer
Microsoft MVP
Professional Development Numbskull

Nyuck nyuck nyuck
 
Kevin -
--Control of desktops = no problems ensuring clients have .net framwork
on pcs
--Client server in that we will be hitting oracle db
--Lan behind firewall
--To best of my knowledge - offshore clients will VPN to a Terminal
Server in US
--No Internet usage
--App behind firewall - security concerns at present (it is a VB6 app)
revolve around data which are handled via roles in Oracle

thks........
 
Hi Brian,

From your list of requirements, and from your description of your network
environment, I think I would recommend building a .Net Windows Forms
application using ClickOnce deployment. ClickOnce is a technology that
enables a Windows Forms application to be installed and updated from a
single network location, and it can even update itself automatically.
Details can be found at:
http://msdn2.microsoft.com/en-us/library/wh45kb66.aspx

The advantage here is that you want a rich user interface, which is
difficult (read "expensive") to develop with a pure web application, which
is a thin-client app using HTML as its primary interface. With a Windows
Form application, it is relatively easy and inexpensive to develop a rich
user interface experience, and with ClickOnce, it is easy to deploy across a
network and easy to maintain/upgrade across a network.

--
HTH,

Kevin Spencer
Microsoft MVP
Professional Development Numbskull

Nyuck nyuck nyuck
 
Hi Brian,

I would like add a new vision which we call an empty client which is
you program in a WinForms model API including design time capabilities
in an environment called Visual WebGui which is actually an extension
to the ASP.NET pipeline and the .NET framework. That provides with all
the you love in WinForms via web. At the end of the day you get a
WinForms like application that runs as a pure AJAX based application in
no time.

check out this app we have just published on SourceForge:
http://sourceforge.net/projects/vwg-ent-man

You can find here more information about Visual WebGui including
videos:
http://www.visualwebgui.com

And here you can download the sources of the SDK and the community
edition which is a free enabling you to test drive Visual WebGui:
http://sourceforge.net/projects/visualwebgui.

Feel free to contact us for more information at:
(e-mail address removed)

Thank you very much
Guy Peled
Gizmox - Visual WebGui
 
Back
Top