Monolith -> layered client/server?

[Microsoft]

I'm about to start converting my application from a old-style monolith exe
(with flat files and limited database support for sharing some of the data)
to a layered .NET SQL server version. I have decided to do it as a Windows
Forms client application, hooking up to a central SQL Server, and then maybe
later create an asp version of the client if needed.

I have a couple of questions on the setup:

1) The clients will be going through the I-net to reach the SQL Server. I'm
assuming I have to set up a VPN for this for security reasons, right?
Exposing SQL server directly would be bad?

2) If so, is this process transparent to the client program, or do I need to
include some code in the client to establish the connection, etc.? E.i. Can
I just use ADO.NET with a simple IP in the connection string (as I do in my
test project) or do I need some VPN SDK to handle the connection?

3) I'm a bit confused about the server side of the application. The way I
see it now, I only need to have the SQL server on that server machine, and
have the client.exe, BL.dll, DAL.dll on the client machines. Is there a need
for an application specific server/service besides the actual SQL server? If
so, what would its purpose be? I see mention of putting the DAL (and BL?) on
the server, but that could only work if you had a running server/service
program receiving requests from the client programs, right? If I already
have a method of automatically updating the client.exe (and any other files
the client has), would there be any point in not having the BL and DAL on
the client side?

Jesper.

 

[Guest]

IMHO

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

That way you can put as many logical layers (data access, business rules,
whatever) on a server talking to your SQL Server...
AND it would save problems with deployment - users navigate to applicaiotn
via browser with no reason for software updates
AND it wouldn't be a problem for future as you laready have ope eye on an
ASP "version" too...

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...
Connection details remain secure on the server BUT can be changed easily
should it be required...

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...
Hence, I reckon ASP.NET is better solution for internal network where all
logic remains in server environment for ease of maintenance...

3) No, you don't NEED anything on the server except the db BUT you are
deploying mulitple instances of your layers to each client...
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...

Better is put layers on server machine and keep thin client for presentation
only - whether Windows Forms or web application...
Advantage of Windows forms? Richer set of controls. No browser requirement...
ASP.NET with subsequent XML/XHTML/JavaScript frontend? Ease of deployment
and maintenance...

You'll end up writing the same back end data access code anyway

(e-mail address removed)

 

[Microsoft]

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.