Re: VB.net and ASP.Net Typed Datasets

"Tiers" are nothing more than classes designed to do one particular type of
job.

If you have a class that does just your business logic (or 27 classes that
do nothing but handle business logic), then you have one tier (made up of
however many classes do the work [1 or 27]) that represents your business
layer. If you have other classes that just handle your data access and
manipulation, then that is another tier. Of course, this code needs to be
called from somewhere (either a web client or a Windows Forms app) and so,
that would be your presentation tier, making your 3rd tier.

I do have some questions/concerns about what you wound up with though. See
my responses inline....

"Rick Vooys" <RickVooys@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:E0EF978D-049D-4D23-BEB3-ADDC80222E56@xxxxxxxxxxxxxxxx
First of all, thanks for all the advice. It really got me moving in the
right
direction.

What I have set up is a web service that will contain the buisnees logic,
it
returns datasets that we use will ADO.net controls.

Your web service *returns* datasets to the caller of the web service (either
an ASP.NET web form or a Windows Form)? This is generally not considered to
be a good idea for scalability reasons. A DataSet is a .NET (Microsoft)
structure. What if, in the future, you decide to make the front-end of the
application a Java Server Page? The DataSet object won't be recognized in
the J2EE environment. Now, I know what you are saying... "That wouldn't
happen." Well, let me just tell you that the last thing you think will
happen in the future is generally the very next thing that will happen in
the future, really!

The whole point of web services is to create a non-proprietary,
platform-independant remote procedure call via http. If your web service
returns a proprietary result, then doesn't that kind of defeat the purpose
of web services in the first place?

DataSets are fine to use and pass back and forth in the back-end of your
application (i.e. between business and data layers) because that part of
your architecture will likely be all the same. But between the web service
and the presentation layer, you should stay as open as possible, hence the
purpose of web services. Instead of passing a DataSet, you should pass the
XML representation of the DataSet (DataSet.GetXML()) or a different form of
XML alltogether (manually created by the business or data layers).

It uses the typed Datasets to access the SQL Server database.

DataSets don't *access* any data. They are merely repositories to store
copies of data.

It can be consumed by either a web application (ASP.net) or with Windows
forms.

See my first comment about not using DataSets for this.

We have still not decided
which route to go with, Web or Windows forms, but the now we have the
ability
to mix/match or switch if we need be.

Yes.

One of the main reasons for the 3 tiered enviroment right.

Yes.

Now isn't this 3 tier? Cor, could you elaborate on your statement?

See my very first comments at the top of this message. Now, you are going
to love hearing this, but I would suggest adding a 4th tier/layer so that
your business logic is NOT handled directly in the web service, but instead
is handled by separate, non web-service classes and use the web service
class to contact the correct business class. So, the progression would be:

Presentation Layer (Web Form or WinForm) makes a request for the web
service.
Workflow Layer (Web Service) calls appropriate business layer class based on
what the Presentation Layer requested.
Business Layer (stand-alone class) processes business logic.
Data Layer (stand-alone class) is called by business layer when data
access/data manipulation is needed.

By squeezing a 4th layer in there (the Workflow Layer, which is the Web
Service), you gain the ability to swap out business layer logic without
changing the interface that the web service caller must call. The web
service becomes nothing more than a proxy class, a pass-through, a traffic
cop or the doorway to the back-end of your application.

Can I get what you guys list as the pros/cons for web vs windows forms?

Web Forms (ASP.NET) benefits:

No client installations/updates/patches.
Platform-independent.
Accessible from any location (that has Internet connectivity).

Web Forms (ASP.NET) deficits:

Doesn't usually perform quite as well as client applications (bandwith).
More support usually required (server maintenance, security, etc.)

WinForms benefits:

Performs well.
Rich set of controls and UI components.

WinForms deficits:

Local installations/updates/patches required.
Requires local machine to have correct .NET Framework version.
Not accessible from anywhere/anytime.

Is is true local file manipulation is a problem from a web application,

Yes.

wouldn't vb.net or C# have file manipluation (import/export from
spreadsheets) built in. Or could it be a sercuity issue?

It's not so much an issue for VB.NET or C#, it's a matter of whether this
VB.NET or C# is running client vs. server side. Server-side code can't
manipulate client-side hard drives because the code doesn't execute on the
client, it executes on the server.

Client-side code CAN manipulate the client hard drive (but client security
settings may still prohibit this activity for obvious reasons), but remember
that .NET code is NOT client-side code UNLESS you are building a WinForms
application. You can still do ASP.NET and do client-side file manipulation
but, it wouldn't be the .NET code doing the work, you'd need JavaScript/VB
Script running locally to do this.


"Cor Ligthert [MVP]" wrote:

This means that the application you create is the middle tier, which is
used
by all your client with the general UI client their browser. This means
that
if you have created layers (by instance a DAL or a BLL) which uses shared
(static in C#) Data than that will be used by all clients, this can make
quite a mash of it, if this is by the client updatable data.

Cor



.