Death of the browser?
Messages   Related Types
This message was discovered on ASPFriends.com 'winforms-community' list.
Responses highlighted in red are from those people who are likely to be able to contribute good, authoratitive information to this discussion. They include Microsoft employees, MVP's and others who IMHO contribute well to these kinds of discussions.

Rob Waggoner (VIP)
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnadvnet/html/vbnet10142001.asp

I read this a while ago when we were trying to figure out what to do with
our VB6 based underwriting application. The article was used as ammunition
to persuade the developers of the group to "start" a win forms based
solution. But! The boss decided that web forms would be a better choice.

The final decision didn't bother me too much, and I feel that *if* we
architect the solution properly, we should be able to swap a win form or a
web form front end in at will.

Thoughts?

AspFriends.com moderation team

Rob Waggoner
WAGGS
Web based Advanced Graphing and Graphic Solutions
http://www.waggs.net
"Applying Old world craftsmanship to New world technologies"

Reply to this message...
 
    
Matthew Reynolds
I'm a very strong believer in "trickle download" features in Windows Forms -
although they're more properly described as ".NET features" as its open to
any kind of code.

As we all know, the best way to develop apps for .NET is to go with the
classic 3-tier design. The business tier is where all the smart stuff
should be (CreateCustomer, GetInvoiceAsXmlDocument, etc.) and the
construction of the actual presentation layer should be entirely separate.

For example, a project I'm working on right now has to take an invoice
stored in a database and express it as an XML document. The important thing
to get right is the production of the document, properly packaged as a
class. The client will then be able to:

- Create a WebForms app that displays the document (create calss, call
method, return text),
- Create a Windows service that can async send the document back (again,
create class, call method, return text),
- Create a WinForms app that takes the XML document and packages it it up
into a number of DataGrid, etc. controls for display.
- Create a *WebForms* app that does the same thing as the WinForms app.

So, Rob, I don't think it's important that they've chosen not to go with
WinForms this time round, as all the magic at the start of the project
should be concentrate on the business tier. However, I'm sure that you'll
be able to come up with some cool business cases to expedite the WinForms
versions - e.g. interactive charting and other rich UI features tricky to
pull off on the Web.

Matthew

-----Original Message-----
From: Rob Waggoner [mailto:Click here to reveal e-mail address]
Sent: 22 January 2002 13:52
To: winforms-community
Subject: [winforms-community] Death of the browser?

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnadvnet/ht
ml/vbnet10142001.asp

I read this a while ago when we were trying to figure out what to do with
our VB6 based underwriting application. The article was used as ammunition
to persuade the developers of the group to "start" a win forms based
solution. But! The boss decided that web forms would be a better choice.

The final decision didn't bother me too much, and I feel that *if* we
architect the solution properly, we should be able to swap a win form or a
web form front end in at will.

Thoughts?

AspFriends.com moderation team

Rob Waggoner
WAGGS
Web based Advanced Graphing and Graphic Solutions
http://www.waggs.net
"Applying Old world craftsmanship to New world technologies"

| [winforms-community] member Click here to reveal e-mail address = YOUR ID
| http://www.asplists.com/asplists/winforms-community.asp = JOIN/QUIT

Reply to this message...
 
    
Gary Lewis
I've designed several applications using the n-tier approach and I can't stress
enough the importance of proper isolation between the UI and BLL. I
whole-heartedly agree with Matthew's assessment and find that given such
separation; the use of Web Forms vs. Windows Forms, becomes less an issue.

The need for separation of the BLL from the DAL layer, however, is less clear.
In the old (!) days, I designed a set of strongly-typed data-centric classes
that were the only code that knew anything about the database. I was able to
further push data-specific issues further "down" in to the database by the use
of sprocs.

With the advent of the DataSet and disconnected access, I find the need for a
fully isolated DAL layer less necessary; i.e. using sprocs and creating the
DataSet in the BLL is not heresy - although there are applications where the
development of a strongly-typed DataSet is attractive. I find that the need for
separation of the BLL and DAL layer is somewhat application-dependent.

Finally, I suggest that if this discussion gets much more focused on
architectural issues, that we move to aspngarchitecture.

Comments?

Gary

-----Original Message-----
From: Matthew Reynolds [mailto:Click here to reveal e-mail address]
Sent: Tuesday, January 22, 2002 06:03
To: winforms-community
Subject: [winforms-community] RE: Death of the browser?

I'm a very strong believer in "trickle download" features in Windows Forms -
although they're more properly described as ".NET features" as its open to
any kind of code.

As we all know, the best way to develop apps for .NET is to go with the
classic 3-tier design. The business tier is where all the smart stuff
should be (CreateCustomer, GetInvoiceAsXmlDocument, etc.) and the
construction of the actual presentation layer should be entirely separate.

For example, a project I'm working on right now has to take an invoice
stored in a database and express it as an XML document. The important thing
to get right is the production of the document, properly packaged as a
class. The client will then be able to:

- Create a WebForms app that displays the document (create calss, call
method, return text),
- Create a Windows service that can async send the document back (again,
create class, call method, return text),
- Create a WinForms app that takes the XML document and packages it it up
into a number of DataGrid, etc. controls for display.
- Create a *WebForms* app that does the same thing as the WinForms app.

So, Rob, I don't think it's important that they've chosen not to go with
WinForms this time round, as all the magic at the start of the project
should be concentrate on the business tier. However, I'm sure that you'll
be able to come up with some cool business cases to expedite the WinForms
versions - e.g. interactive charting and other rich UI features tricky to
pull off on the Web.

Matthew

-----Original Message-----
From: Rob Waggoner [mailto:Click here to reveal e-mail address]
Sent: 22 January 2002 13:52
To: winforms-community
Subject: [winforms-community] Death of the browser?

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnadvnet/ht
ml/vbnet10142001.asp

I read this a while ago when we were trying to figure out what to do with
our VB6 based underwriting application. The article was used as ammunition
to persuade the developers of the group to "start" a win forms based
solution. But! The boss decided that web forms would be a better choice.

The final decision didn't bother me too much, and I feel that *if* we
architect the solution properly, we should be able to swap a win form or a
web form front end in at will.

Thoughts?

AspFriends.com moderation team

Rob Waggoner
WAGGS
Web based Advanced Graphing and Graphic Solutions
http://www.waggs.net
"Applying Old world craftsmanship to New world technologies"

| [winforms-community] member Click here to reveal e-mail address = YOUR ID
| http://www.asplists.com/asplists/winforms-community.asp = JOIN/QUIT

| [winforms-community] member Click here to reveal e-mail address = YOUR ID
| http://www.asplists.com/asplists/winforms-community.asp = JOIN/QUIT

Reply to this message...
 
 
System.Data.DataSet
System.Web.UI.WebControls.DataGrid
System.Windows.Forms.DataGrid




Ad
MBR BootFX
Best-of-breed application framework for .NET projects, developed by Matthew Baxter-Reynolds and MBR IT
 
 Copyright © Matthew Baxter-Reynolds 2001-2008. '.NET 247 Software Development Services' is a trading style of MBR IT Solutions Ltd.
Contact Us - Terms of Use - Privacy Policy - www.dotnet247.com