Basic Architecture

  • Thread starter Thread starter Todd
  • Start date Start date
T

Todd

Where do I place my code? I am learning VS.NET 2003 but
have a big picture question on how to build applications.
The way I see it, I have three places I can place code. I
can place code on the webserver (front end), the
application sever(s), and the back-end SQL Server. It
seems to me, the best practice is to place as much code on
the SQL Server (called through triggers) and on the
middle "application server" and as little as possible on
the web server. Is this correct? I have been studying many
ASP.NET and VB.NET books, and it seems no one addresses
this design topic clearly.
 
Hi Todd,
Where do I place my code? I am learning VS.NET 2003 but
have a big picture question on how to build applications.
The way I see it, I have three places I can place code. I
can place code on the webserver (front end), the
application sever(s), and the back-end SQL Server. It
seems to me, the best practice is to place as much code on
the SQL Server (called through triggers) and on the
middle "application server" and as little as possible on
the web server. Is this correct? I have been studying many
ASP.NET and VB.NET books, and it seems no one addresses
this design topic clearly.

You say have an WebServer, an Application Server and an SQL server.

What I know in very short words is that the WebServer/Applications Server is
the IIS/ASP.Net server. An integrated server (or more if necessary using
load balancing) where all the programming code is placed that has to do with
Web applications, it delivers on request of the client window program or a
webforms the information that is needed.

That can be delivered using HTML/XML, as XML files or XML datasets or just
messages using Webservices.

The SQL server is a supplier of data which can be supplied using stored
procedures or just with an SQL script.

What you describe sounds to me as an Oracle concept.

But maybe I am wrong?

Cor
 
Todd,
With the power of ASP.NET, I would place the bulk of my code in ASP.NET. I
would use stored procedures on SQL Server, largely handling CRUD (Create,
Retrieve, Update, Delete). I would resort to a trigger only if there was an
interface to the data that did not allow the use of stored procedures.

I would only get an "application server" involved, if I really need one. If
I used an "application server" I would favor .NET Remoting over Web Services
for communication, as I find Web Services are more for external interfaces
to your app, not internal interfaces between layers.

Of course my ASP.NET code would be fully OOP.

Hope this helps
Jay
 
Wow. So what is being said by you and Jay is I don't need
an "application server" to host the bulk of my code. My
code should be placed on the web server. Is that correct?
 
Todd,
Yes, that I what I am saying, you MAY not need an "application server" at
all.

Without knowing more of the specifics on your project it is hard to say
either way.

Generally I separate my app into logical layers, not physical layers.

Hope this helps
Jay
 
Hi Todd,

For some reason your message was set as "read", but I saw the answer from
JayB.

So I answer too.

The only thing I want to add is, I would not call it a webserver, because a
..Net webapplication is more than a dumm HTML webpage. It uses a .Net server
(or a load balandced group of servers) what is a combination of a Web and
Serverside application server.

Cor
 
Back
Top