Basic Architecture 2

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

Todd

I need clarification on how an application should be
structured. In my mind, you should have a data base sever,
a middle server to host a bulk of the code, and a front
end web server. However, I have received input that I
should build my application in ASP.NET and running on the
web server. Does this seem strange to anyone? It is normal
to push application execution to the webserver? How can
that scale? Why would a web server also execute the
application's core code? Am I missing Microsoft's concept
for building .NET applications? Are most people building
their web interfaced .NET application to execute on their
web servers?

Thank you in advance. Todd
 
I want a web interface.

For application with web interfaces, should the bulk of
the code execute on the web server, or should there be a
middle server(s) executing the bulk of the code?
 
Hi Todd,

Here is how I structured my .Net apps :

PageOne.aspx : contained the HTML server-side controls
and the events associated with them. eg:

<%@ Page Language="vb" AutoEventWireup="false"
Codebehind="PageOne.aspx.vb"
Inherits="SITENAME.SiteClassName" SmartNavigation="True" %
<TABLE>
<TR>
<td align="right"><asp:button id="cmdSubmit"
tabIndex="17" runat="server" Height="23px" width="59px"
Text="Submit"></asp:button>
</td>
</TR>
</TABLE>

(...)

<script language="vb" runat="server">
Private Sub cmdSubmit_Click(ByVal sender As
System.Object, ByVal e As System.EventArgs) Handles
cmdSubmit.Click
SubmitOrder()
End Sub

</script>

PageOne.aspx.vb : contains all the code that related to
the GUI (the aspx page)
It gets its data from Business class contained in a DLL
residing in the 'bin' directory of the web-site.

COMPONENT.DLL : contais all my business rule and
interacts wioth the data access component

DATAACCESS.DLL : connects to the dB.

It is all weel broken down, every component or layer has
its responibilities and they don't mix.

I have been working like this for months and it work
magic for me ! I have spent a lot of time creating
generic classes in COMPONENT.DLL and I got a tremandous
amount or reusibility. I could virtually copy and past
one class from one project to the next with hardly any re-
write and sometimes not at all. For example, a class
handling LDAP queries, another one sending SMTP mails,
one dealing the System.IO class, one producing Crystal /
PDF reports, etc.

There would be a lot more to say more that should be you
started... and thinking !! ;o)

Hope this helps...

Ben
 
Tnank you Ben. That does help. It shows that all the code
executes on the web server. I find that very interesting.
It shows one must seriously protect the web server.
Additionally, it seems like the application may eventually
overload the web server. Apparently .NET doesn't scale
well since everything needs to run on the edge of the
network on the a web server. Once the web server hardware
is configured with maxium memory and processors, there is
no where to go. The system will hit a capacity wall in
regards to the ability of the application to handle more
clients and code. I wish there was a way to build a system
so it could be distributed to run on multiple computers,
and the web server only served up the interface.
 
There is no reason to put everything on the same machine, you can use
WebServices for the Business Logic, ...

ex:

Presentation layer: Webserver1 and Webserver2 (both servers in DMZ, only
webinterface, codebehind handling UI events and calling WebServices on
internal application server(s))

Business layer: Application server(s) running WebServices (Business Logic,
connecting to datasources, ...)

Database layer: Internal Database server running SQL Server 2000, Oracle,
....

Now you have a way to spread your load, add more webservers if necessary,
add application servers, ....
 
There is no reason to put everything on the same machine, you can use
WebServices for the Business Logic, ...

ex:

Presentation layer: Webserver1 and Webserver2 (both servers in DMZ, only
webinterface, codebehind handling UI events and calling WebServices on
internal application server(s))

Business layer: Application server(s) running WebServices (Business Logic,
connecting to datasources, ...)

Database layer: Internal Database server running SQL Server 2000, Oracle,
....

Now you have a way to spread your load, add more webservers if necessary,
add application servers, ....
 
If you start running out of capacity, just add another web server using
something like Application Center. You could also use load-balancing
hardware in front of the web servers.

You can also move a lot of the middle layer onto a different machine and use
remoting or web services to communicate.

Colin
 
You have to first of all decide what interface ur user wants to use, web or
desktop app. Fm there starts the q of architecture.
 
I need clarification on how an application should be
structured. In my mind, you should have a data base sever,
a middle server to host a bulk of the code, and a front
end web server. However, I have received input that I
should build my application in ASP.NET and running on the
web server. Does this seem strange to anyone? It is normal
to push application execution to the webserver? How can
that scale?
Click to expand...

The main point here is that there is no single "should". It depends on
your needs. I do think it's important to logically separate the middle
layer from the presentation layer, but whether you want to physically
separate them by using web services or something is totally dependent on
the application you're building.

Personally, I think that running the business layer on the web server is
fine for the overwhelming majority of applications out there, and I tend
to do the same thing someone else posted: put the app .dll in the bin
directory. Sure, it hurts scalability somewhat, but a) it makes
maintenance easier, b) most servers these days have a lot of room to
scale, and c) as long as your initial design kept the layers fairly
clean, it's not all that tough to move the middle tier to an application
server later if you need to.

It all depends on how complex your middle tier is, how much scalability
you're likely to need, etc. There's nothing in ASP.NET that forces the
business logic to be on the web server, in fact it's a bit easier to use
an n-tier architecture in .NET than it is in most other web programming
systems (a broad statement, but I'm purposely ambiguous there).
 
Back
Top