Hi,

What's in general the most performant for a VB.NET Windows Forms (2.0)
application:
- a fat client (everything one the client, the server hosts only the
database)
- a smart client (an application on the client, that communicates with an
application on the server via Webservices/Remoting/..)

I would somehow think a smart client, but would just like to have the
opinion of others :-)

Thanks a lot in advance,

Pieter

Pieter,

Definitly a Fat client if your company want to spent as less money overall
and wants the most efficiency from the total system.

Definitly smart client, if your company is by instance a company who want to
invest more millions in Big Central computer systems and a very expensive
LAN's and only very few money in client systems.

(This based on an application inside a LAN, if it is on the Interenet than
your objectives are for me to raw).

Everything on the Client does for me not mean consequently on the client,
data can be retrieved from the database in very small parts.

Just my thought,

Cor

Show quoteHide quote

Pieter Coucke wrote:
Show quoteHide quoteIt is much easier for unexperienced programmers to create a fat-client
reading data directly from the database. It will probably be also more
performant. But if you have a team with experience in web
services/xml/http/web servers you can create a smart client application.
It could be more scalable than a fat-client application and much easier
to maintain (provided that the client app does not change frequently).
Why not use web browser as a smart client? I do such systems in my
company and we have developed quite a powerful framework for
browser-based smart client systems.

rg

I would go with a Smart client because it buys you the most flexibility.

Also, a smart client does not involve much more effort than a standard fat
client.

I have to agree with Cor, with the proviso that you should enable
flexibility in your fat client (abstract any data access methods).  This is
easy with the project I am working on.  I have an abstract DataConnection
class with all of the methods I need in order to manipulate the data store.
I use a class factory to create whatever connection type I need, derived
from DataConnection, including SQL Server, Oracle, DB2, MySQL and SOAP.
It's just the same as writing a "middleware" library, except you contain the
library within your fat client, rather than outside it.



Show quoteHide quote

The definitions for "fat" or "smart" clients are so vague, that either
definition would fit either of the implementations you describe...

There are several factors that you should consider when deciding on the
architecture:

one more layer between the user and the database that the user (or
someone impersonating a user) can not tamper with.

use the server logic in a webserver type architecture to minimize traffic.

reconfiguring any firewalls or routers on the way.

layer that enables you to do changes in the database architecture
without the need to deply a new version of the client program.

...and probably some more that I can't think of right now.

Pieter Coucke wrote:
Show quoteHide quote

screw .net and screw thin clients.

i woudl reccomend Access Data Projects.
simple data entry apps.

it works allright against sql 2005; but you've got to use SSMS to write
objects once you get your data in SQL 2005.

and it's fast as snot.

Concerning network limitations: Which consumes the most network bandwith?
- webservices
- remoting
or
- a fat client (without application server)?

Pieter,

Without any further information, than it is in equal situation for sure a
webservice which has the less performance, just because it uses XML which
needs the tags and is non compressed.

You would however be a fool if you would use that as critera.

There are given in this thread some better criteria to decide.

Cor

Show quoteHide quote

I do agree, but I was talking some days ago with a company that used this as
an argument :-) So I wanted to know if somebody had an exact impact of it on
the bandwith :-)

Pieter wrote:
Webservices uses more bandwith than remoting, at least if they are used
the same way. (Webservices is a lot easier to build and use, though.)

How that performs compared to the other depends a lot on how much data
you have to access to do the business logics.

A huge question and not one easily answered.  I guess in a nutshell it all
depends on what your requirement actually is, and what skilled resources you
can call on, your security needs, your data access restrictions.  I would
never chose a technology platform and deployment approach because it might
be faster-it could be a wholly innapropriate choice in the end.

For example - If its an application for 10 desktop users thats heavily into
working with the local registry wheree performance is absolutely paramount
then a smart clients unlikely to cut it, however if you have thousands of
distributed users on an extranet type scenario using different access
devices then smart client may be appropriate, but then maybe a well defined
web app would do just as well.  That said, poorly specced hardware will
cause any web server setup to grind to nothing, so your performance dies
with it.

As an architect, you should consier all of these things and also consider
the cost of future proofing the application - whats the likely direction of
the app - if its heading for smart phones and the web then theres not a lot
of point in building a fat client that will only sit well on a pc as you'll
have to do it all later.

Show quoteHide quote

OOP Best Practices Part 2
Initial value of uninitialized variables in C# (reference type)
architecture question
How to Implement Dynamic Roles
Object oriented best practices