Re: Monolith -> layered client/server?

Tech-Archive recommends: Fix windows errors by optimizing your registry

From: Microsoft (no_at_spam.com)
Date: 08/24/04 

Date: Tue, 24 Aug 2004 17:07:02 +0200

> Why not just build ASP.NET system straight off as (non-presentation) code
> would be practically the same.

I have several issues with ASP.NET. My application relies heavily on rich
controls that I currently have no ASP.NET equivalent for. The 'rich' feel is
the number 1 reason my user like my current program. Secondly, I'm a little
worried about scalability and response time when 'flipping though' data
(current responsiveness of the UI is basically instant). If the application
experiences 'pauses' like when clicking links in IE (ranging from 1 second
to ?) and/or page reloads everytime the user changes a value or decides to
view a new range of data, then this is a definataly bad.

> 1) I'd have a specific SQL Server user account for the application and
> ALWAYS access the db through that...
> Use stored procedures and/or SQL created on the fly by the application if
> required. SP's are better for security reaons AND the db can optimise
> execution...

Agreed. Already doing this just for optimal use of connection pooling.

> 2) Client would require db connection info. Using a windows app on the
> client MIGHT be problematic if for any reason your db conneciton details
> change...

I agree this can be a problem, although I concider it to be minor in my
case, as I'm going to have a feature that lets clients get updated with
planned server changes. Only unplanned changes will be a problem.

> Why build layers in this case? Yes you are benefitting from logical
> extrapolation of functionality but that's about it...
> AND you stirring up depolyment problems for new releases (clients out of
> synch) and ooh! lots of things...

Yes, I'm using layers basically only for the logical seperation. The
deployment issue has been taken care of already, so I don't really concider
it a problem.